-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Martin,
On 1/11/13 9:26 PM, Martin Gainty wrote:
>>
>> 1. The ciphers parameter in Connecter determines the enabled
>> cipher suites in the SSLSocket. See
>> SSLSocket.setEnabledCipherSuites(). That in turn restricts which
>> actual cipher suite can be negotiated with the client, depending
>> also on the client's cipher suites and how JSSE chooses among
>> those that intersect. MG>understood
>>
>> 2. The private key itself doesn't have any 'supported ciphers'
>> so your question is already meaningless. However (a) it does have
>> a *type*, which is generally RSA or else DH, and (b) it
>> corresponds to a single X.509 certificate which contains a public
>> key in the same type or format.
>
> MG>yes the public key would implement RSA or DH or Idea or some
> other *type*
You are still confusing things: IDEA is another symmetric block-cipher
like AES, DES, 3DES, etc. Public keys implement nothing: they are just
keys algorithms. The algorithms most popular for X509 keys are RSA and
DSA.
>> If the server requests a client certificate, it (i.e. JSSE, not
>> Tomcat) sends an SSL <CertificateRequest> message, which contains
>> a list of acceptable certificate types and a list of acceptable
>> signers.
>
> MG>thus the choice for cipher suites is now assigned
No, this still has nothing to do with cipher suites: the server is
telling the client that it's only okay to send X509 (as opposed to
some other type of certificate) and that it will only accept
certificates that are signed by some authority. (I'm skeptical that
the server can actually tell the client that it will only accept, say,
Verisign-signed certificates -- I'm fairly sure the client has to send
the certificate before the server can reject it).
> MG>reprising the publicKey signer algorithm to cipher suite
Not relevant, whatever that means.
> MG>With a RSA (public)key you can nominally use the "RSA" and
> "DHE_RSA" cipher suite. But if the server certificate has a Key
> Usage extension which does not include the "keyEncipherment" flag,
> then you are nominally limited to "DHE_RSA".
You do realize that there is a difference between "key encipherment"
(that would be the cipher used to encrypt the key) and "data
encipherment" (the cipher used to encrypt the actual data), right? The
former is all about the key and the latter is all about the block
cipher used to actually send non-key data back and forth from the
client to the server.
The "cipher suite" setting chooses the "data encipherment" ciphers
that are acceptable to the server.
An X509 certificate's "Key Usage" section can only limit the usage of
the certificate for various purposes (e.g. encryption, signing,
code-signing, email encryption, repudiation, etc. Just Google for
"X509 Key Usage Extension" and you'll find loads of accurate
information that you can read instead of us having to teach you about
PK infrastructure.
> MG>With a DSA (public) key you can use only a "DHE_DSS" cipher
> suite.
I'm waiting for my Amazon ELB to redeploy with a test DSA key (those
things are a PITA to create). Running sslscan will see what happens.
> MG>With a Diffie-Hellman (public) key, you can use only one of
> "DH_RSA" or "DH_DSS", depending on the issuing certificate
> authority key type.
There is no such thing as a Diffie-Hellman key. D-H is a key
/exchange/ protocol. Look:
$ openssl ciphers -v
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
...
You can use D-H key exchange with both types of certs (and keys): RSA
and DSA.
>> If the client certificate isn't one of those types or isn't
>> signed by one of those signers it isn't sent
> MG>the choice is made!
Note that we're still not talking about cipher suites: we're talking
about certificate acceptability, which is part of the key exchange
protocol.
>> and if the Web resource being requested is defined as requiring
>> SSL client authentication, Tomcat would then deny access.
>
> MG>lets look at the guts of a public key to clarify whats going on
Let's.
> MG>keytool -list -v -keystore NotForOutsideUse.jks Keystore type:
> JKS Keystore provider: SUN Your keystore contains 1 entry Alias
> name: Alias Creation date: Apr 24, 2012 Entry type:
> PrivateKeyEntry Certificate chain length: 1 Certificate[1]: Owner:
> UID=999999, EMAILADDRESS=paynom...@paynomind.com, CN=BigBank,
> OU=99999999, O=BigBank.com Issuer: UID=IssuingAuthority,
> CN=CanonicalName, OU=IT Security, O=CanonicalName Serial number:
> 99999999999999999999999999999999 Valid from: Tue Apr 24 12:21:00
> EDT 2012 until: Fri Apr 24 12:21:00 EDT 2015 Certificate
> fingerprints: MD5: SHA1: Signature algorithm name:
> SHA1withRSA Version: 3 </snip>
>
> lets look at the log produced by TC when Public key
> =NotForOutsideUse.jks request is made in the JSSE Key Exchange
Note that NotForOutsideUse.jks is a key /store/, not a key. It
probably contains a key, but it's got more than that.
> keyStore is : NotForOutsideUse.jks keyStore type is : jks
>
> init keymanager of type SunX509 found key for : {Omitted} chain [0]
> = [ [ Version: V3 Subject: UID=999999, CN=CanonicalName ID: 999999,
> OU=99999999, O=paynomind.com Signature Algorithm: SHA1withRSA Key:
> Sun RSA public key, 2048 bits modulus: Omitted public exponent:
> 99999 Validity: [From: Fri Dec 10 11:29:21 EST 2010, To: Mon Dec 09
> 11:29:21 EST 2013] Issuer: UID=PayNoMind, CN=CanonicalName,
> OU=Dept1, O=PayNoMind SerialNumber: [ Omitted ] EXAMPLE
> CONCLUSION: the JSSE Key exchange is implementing SSLV3 Protocol
> AND RSA Signing Algo
>
> from the eligible ciphers listed here
> http://www.openssl.org/docs/apps/ciphers.html could the server
> implement IDEA-CBC-SHA cipher (if listed in Tomcat <Connector
> ciphers="IDEA-CBC-SHA " ...>
Why not?
> My understanding is there can be NO handshake as there is a
> mismatch BETWEENSigning Algo already in use (RSA) with the Signing
> Algorithm identified by the cipher (IDEA) from the ciphers
> parameter
RSA is for key authentication.
IDEA is for data encryption.
They are separate things.
Read this page, /please/: http://en.wikipedia.org/wiki/Cipher_suite
The "ciphers" listed in the cipher suites attribute combines key
exchange, authentication, block cipher, and MAC all into one big
string (like IDEA-CBC-SHA). Some of them are mutually exclusive (I
don't think you can use DSA to authenticate an RSA key, for instance)
but you have been madly ranting about being unable to use block
ciphers which simply isn't true.
Try this on your machine:
$ openssl ciphers -v 'IDEA'
I evidently don't have IDEA compiled-into my openssl, as this command
returns nothing for me. On the other hand, I do have CAMELLIA ciphers
if for some reason that rings truer than AES:
$ openssl ciphers -v CAMELLIA
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA1
ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256)
Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128)
Mac=SHA1
ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128)
Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA1
Note that I can use this cipher with either DSA or RSA keys.
Key/cert algorithm simply has no bearing on the block ciphers
available to you. You may have to use different key exchange and
authentication algorithms, but that's because those keys/certs and
those algorithms must go together.
Still, it has no bearing on the block cipher used to actually send the
"real" data back and forth.
I have an RSA key in production. Today, I ran a scan of all requests
that we got over the last 8 months (as long as I have this data) and
the cipher suites used for those requests.
Here's what we got, from most-popular to least-popular:
RC4-SHA
RC4-MD5
AES128-SHA
DHE-RSA-AES256-SHA
AES256-SHA
DES-CBC3-SHA
DHE-RSA-AES128-SHA
EDH-RSA-DES-CBC3-SHA
Unless you think I'm lying, then I can clearly use DHE (of course!)
with an RSA key: it's using D-H for exchange, then RSA for
authentication. I can also do DES-CBC3. What you won't find in there
is anything having to do with DSS because they are simply incompatible.
But, that's not really a problem: yes, when you pick a key type (RSA,
DSA) you are "restricting" yourself to certain cipher suites that
include that type of key. But, the same cipher suites are generally
available whether you use one key type versus the other.
Examples: you want AES-128 block cipher.
DSA cipher suite:
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128)
Mac=SHA256
RSA cipher suite:
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128)
Mac=SHA256
Look, they even have the same MAC algorithm.
You want CAMELLIA? RSA:
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA1
DSA:
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA1
So, the choice of DSA versus RSA key seem to make a huge difference if
you focus on one specific point of the whole alphabet soup that is
TLS, it's really not a big deal because you haven't ruled-out much
simply by making that key-type choice.
I hope that you actually read everything I wrote instead of having
flipped the bozo bit on me. If not, at least someone else might have
read it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEAREIAAYFAlDw+OIACgkQ9CaO5/Lv0PDvygCeM5cUwQDW2bGrW5Psc5aj/s5E
TbgAnRlB2egYrScjF5Ja9HSCiWLCcVm7
=Of1t
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
