You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Julius Davies <ju...@gmail.com> on 2006/11/17 21:00:05 UTC
questions about commons-ssl
Hi, Oleg, Roland, et al,
I just have a few questions and a few comments. I don't want to pester
anyone too much, so I'm limiting myself to one query a month about the
status with the software grant we sent in August. I'm also trying to make a
point of always adding at least one more feature to the code for every
pestering email. :-)
1. Does anyone know what the status is with the software grant CUCBC sent
in for commons-ssl? I want to wait until we get that all sorted out before
going any further along the incubation path.
2. I recently added support for PKCS8 and OpenSSL format private keys.
It's alpha quality at the moment. I've only announced it here for now while
I try to iron out any bugs. But if you guys like the feature, I'm thinking
of also announcing on OpenSSL and BouncyCastle's mailing lists.
OpenSSL might find it interesting to see all of their formats supported in
Java like that. Plus they probably get the occasional java question, so
they can refer to commons-ssl when appropriate. I'm also curious why CFB
and OFB mode always result in "NoPadding", whereas CBC and ECB result in
"PKCS5Padding". This happens both with the OpenSSL "traditional" encryption
(which is fine, it's their format!), but also with the PKCS8 Version 2 using
DES1, or AES. Personally I don't know encryption well enough, and I don't
know the PKCS8 standard well enough to say that they're doing things wrong,
but it just seemed odd.
BouncyCastle just might like to see how awesome they are. They're the only
one who totally supports all the formats on Java 1.3. I'm thinking of even
adding support for DESX and CAST5 just to show off how much BouncyCastle
rocks (I anticipate that they will support those - maybe not?).
3. The one supreme goal of the library is to no longer require the user to
know their "keystoreType". Just hand me the files, the password, and I'll
figure the rest out. The far off distant dream that gives me hope and
sustains me while writing this library is this....
Imagine a tomcat/conf/server.xml file where.....
Tomcat was sharing the SAME https cert that apache had, while listening on
port 8443....
(Hopefully the <!-- XML --> comments will help prevent people hitting this
email off google from thinking Tomcat actually supports this!)
<!-- hypothetical example that doesn't actually work - don't try this at
home, kids! -->
<Connector
port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" disableUploadTimeout="true" acceptCount="100"
debug="0" scheme="https" secure="true" sslProtocol="TLS"
clientAuth="false"
keystoreFile="/etc/httpd/conf/ssl.key"
associatedCertificateChain="/etc/httpd/conf/ssl.crt"
>
<!-- hypothetical <ssl> node for finer-grained control -->
<!-- NOTE: purely hypothetical - not supported at all! -->
<ssl>
<!-- if client presents client cert, must be signed by one of these: -->
<trust-entry>CACERTS</trust-entry>
<trust-entry>/path/to/certificate.pem</trust-entry>
<trust-entry>/path/to/certificate.der</trust-entry>
<trust-entry>/path/to/pkcs7_chain.pem</trust-entry>
<trust-entry>/path/to/pkcs7_chain.der</trust-entry>
<trust-entry>/path/to/jks_certs.jks</trust-entry>
<check-crl>true</check-crl>
<enabled-protocol>TLSv1</enable-protocol>
<enabled-protocol>SSLv3</enable-protocol>
<enabled-protocol>SSLv2Hello</enable-protocol>
<enable-cipher>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</enable-cipher>
<enable-cipher>TLS_DHE_DSS_WITH_AES_192_CBC_SHA</enable-cipher>
<enable-cipher>TLS_DHE_DSS_WITH_AES_256_CBC_SHA</enable-cipher>
</ssl>
</Connector>
associatedCertificateChain="/etc/httpd/conf/ssl.crt" can still be used even
if the "keystoreFile" is JKS or PKCS12. That's because commons-ssl goes to
some trouble to build up a proper certificate chain using the
X509Certificate.verify( PublicKey ) method. So if PKCS12 or JKS only
contained a single certificate, the user could add additional ancestors to
the chain for presentation during the handshake through this parameter.
Not sure why GMail made my font go funny at this point.
yours,
Julius
http://juliusdavies.ca/
Re: questions about commons-ssl
Posted by Roland Weber <ht...@dubioso.net>.
Hello Julius,
I can't comment on most of your notes, but at least I have something
to say about this one:
> I'm also curious why CFB
> and OFB mode always result in "NoPadding", whereas CBC and ECB result in
> "PKCS5Padding".
It's been a decade that I had to do with it, so I can't explain all
the details by heart. ECB stands for Electronic Code Book, where each
block is encrypted individually. That requires padding to block size.
CBC is Cypher Block Chaining, each encrypted block is fed back into
the next block of data to be encrypted. Again, padding to block size
is required. CFB is Cypher FeedBack, OFB is Output FeedBack. One of
them doesn't even consider the data to be encrytped. It just keeps
on encrytping and re-encryting an initial value like a random number
generator. These random numbers are then XORed to the plain text.
While the loop for generating the random numbers always works with
block size, there is no problem in just taking a part of that block
when XORing, so no requirement for padding the input. I don't remember
the details of the last one, but it also uses a strategy that does not
require padding of the input data.
Since "Applied Cryptography" is a very expensive book, I recommend
Wikipedia for a more detailed description:
http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
Re: questions about commons-ssl
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2006-11-17 at 15:00 -0500, Julius Davies wrote:
> Hi, Oleg, Roland, et al,
>
> I just have a few questions and a few comments. I don't want to pester
> anyone too much, so I'm limiting myself to one query a month about the
> status with the software grant we sent in August. I'm also trying to make a
> point of always adding at least one more feature to the code for every
> pestering email. :-)
>
> 1. Does anyone know what the status is with the software grant CUCBC sent
> in for commons-ssl? I want to wait until we get that all sorted out before
> going any further along the incubation path.
>
Hi Julius,
We have absolutely no control over this process. Have you received any
response from human-response@apache.org? Where did things get stuck?
Oleg
> 2. I recently added support for PKCS8 and OpenSSL format private keys.
> It's alpha quality at the moment. I've only announced it here for now while
> I try to iron out any bugs. But if you guys like the feature, I'm thinking
> of also announcing on OpenSSL and BouncyCastle's mailing lists.
>
> OpenSSL might find it interesting to see all of their formats supported in
> Java like that. Plus they probably get the occasional java question, so
> they can refer to commons-ssl when appropriate. I'm also curious why CFB
> and OFB mode always result in "NoPadding", whereas CBC and ECB result in
> "PKCS5Padding". This happens both with the OpenSSL "traditional" encryption
> (which is fine, it's their format!), but also with the PKCS8 Version 2 using
> DES1, or AES. Personally I don't know encryption well enough, and I don't
> know the PKCS8 standard well enough to say that they're doing things wrong,
> but it just seemed odd.
>
> BouncyCastle just might like to see how awesome they are. They're the only
> one who totally supports all the formats on Java 1.3. I'm thinking of even
> adding support for DESX and CAST5 just to show off how much BouncyCastle
> rocks (I anticipate that they will support those - maybe not?).
>
> 3. The one supreme goal of the library is to no longer require the user to
> know their "keystoreType". Just hand me the files, the password, and I'll
> figure the rest out. The far off distant dream that gives me hope and
> sustains me while writing this library is this....
>
> Imagine a tomcat/conf/server.xml file where.....
>
> Tomcat was sharing the SAME https cert that apache had, while listening on
> port 8443....
>
> (Hopefully the <!-- XML --> comments will help prevent people hitting this
> email off google from thinking Tomcat actually supports this!)
>
> <!-- hypothetical example that doesn't actually work - don't try this at
> home, kids! -->
> <Connector
> port="8443" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
> enableLookups="false" disableUploadTimeout="true" acceptCount="100"
> debug="0" scheme="https" secure="true" sslProtocol="TLS"
> clientAuth="false"
>
> keystoreFile="/etc/httpd/conf/ssl.key"
> associatedCertificateChain="/etc/httpd/conf/ssl.crt"
>
> >
> <!-- hypothetical <ssl> node for finer-grained control -->
> <!-- NOTE: purely hypothetical - not supported at all! -->
> <ssl>
> <!-- if client presents client cert, must be signed by one of these: -->
> <trust-entry>CACERTS</trust-entry>
> <trust-entry>/path/to/certificate.pem</trust-entry>
> <trust-entry>/path/to/certificate.der</trust-entry>
> <trust-entry>/path/to/pkcs7_chain.pem</trust-entry>
> <trust-entry>/path/to/pkcs7_chain.der</trust-entry>
> <trust-entry>/path/to/jks_certs.jks</trust-entry>
>
> <check-crl>true</check-crl>
>
> <enabled-protocol>TLSv1</enable-protocol>
> <enabled-protocol>SSLv3</enable-protocol>
> <enabled-protocol>SSLv2Hello</enable-protocol>
>
> <enable-cipher>TLS_DHE_DSS_WITH_AES_128_CBC_SHA</enable-cipher>
> <enable-cipher>TLS_DHE_DSS_WITH_AES_192_CBC_SHA</enable-cipher>
> <enable-cipher>TLS_DHE_DSS_WITH_AES_256_CBC_SHA</enable-cipher>
> </ssl>
> </Connector>
>
>
>
> associatedCertificateChain="/etc/httpd/conf/ssl.crt" can still be used even
> if the "keystoreFile" is JKS or PKCS12. That's because commons-ssl goes to
> some trouble to build up a proper certificate chain using the
> X509Certificate.verify( PublicKey ) method. So if PKCS12 or JKS only
> contained a single certificate, the user could add additional ancestors to
> the chain for presentation during the handshake through this parameter.
>
> Not sure why GMail made my font go funny at this point.
>
> yours,
>
> Julius
>
>
> http://juliusdavies.ca/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org