>
> 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*
> 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
MG>reprising the publicKey signer algorithm to cipher suite
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".
MG>With a DSA (public) key you can use only a "DHE_DSS" cipher suite.
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.
>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! 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 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
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 "
...>
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
is this not the case?
>
> Connection between (1) and (2): zero. MG>agreed
>
> EJP
>
> -----Original Message-----
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Friday, 11 January 2013 2:35 PM
> To: Tomcat Users List
> Subject: RE: Restricting ciphers
>
>
> its a simple question what does ciphers parameter in Connector have anything
> to do with the supported ciphers from the key itself the 2 are disconnected
> please dont waste my time and anyone elses with insults when you are unable
> to answer this simple question Martin Gainty
> ___________________________________________ When Free Speech and Discovery
> are replaced by Confusion and Obfuscation its time to move > Date: Thu, 10
> Jan 2013 18:25:02 -0500
> > From: ch...@christopherschultz.net
> > To: users@tomcat.apache.org
> > Subject: Re: Restricting ciphers
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Martin,
> >
> > Honestly, I'm not sure why I'm feeding the troll at this point. Maybe
> > I'm trying to atone for some horrible crime I can't remember.
> >
> > On 1/10/13 10:05 AM, Martin Gainty wrote:
> > > terminology :
> >
> > Nobody was arguing about terminology. Next time, just refer to
> > Wikipedia like everyone else.
> >
> > > All you don't know is whether those certificate & private key are
> > > RSA or DSA algorithms
> >
> > It doesn't matter: you can use RSA (like everyone does) or DSA and
> > that will only determine the type of key you have. The cipher can (and
> > will, since SSL/TLS encryption is symmetric and not PK) use a
> > different algorithm for encryption.
> >
> > > you see if it's an RSA or DSA key (along with the key size).
> >
> > Again, key size is only relevant for people who think that bigger is
> > better. You can create a 16k key and it won't be much more secure than
> > an 8k key. Stronger crypto, yes, but nobody tries to guess SSL keys:
> > they use compression (e.g. CRIME) and other nasty tricks so they don't
> > have to do the hard work of key-cracking.
> >
> > > cipherGroup is categorised by keysize within cipher-groups (usually
> > > a 4digit number which is a power of 2 e.g. 1024 and 2048)
> >
> > Sorry, ciphers and keys are not interchangeable: keys usually have 1k,
> > 2k, 4k, etc. bits in them while symmetric ciphers usually max out at
> > 256-bit key sizes. Try running some of the commands you are grabbing
> > off the web to see what I'm talking about.
> >
> > I've never heard the term "cipherGroup".
> >
> > > ECB, CBC and PCBC are the usual choices for the optional
> > > ModeOfOperation parameter Determining the ALGO-CIPHER supported by
> > > your key so we can see that public keys contain a algorithm-cipher
> > > combination but how to determine the algo-cipher supported by your
> > > key:
> >
> > Sorry, your key can support (essentially) arbitrary ciphers. Your key
> > type has no bearing on whether or not ECB, CBC, etc. can be used.
> >
> > > keytool -list -v -keystore fubar.pfx -storetype PKCS12 Here is
> > > output: Certificate fingerprints: MD5: SHA1:
> > > Signature algorithm name: SHA1withRSA Providers (SUN, SunJCE,
> > > SunJSSE,SunRsaSign, IBMJSSE, bcprov-jdkNN-MMM) Lets stick with
> > > SunJSSE as our provider supported ciphers will be those ciphers
> > > which match SHA1 with RSA from this list:
> >
> > Wrong again: the signature algorithm used to fingerprint your own key
> > has no bearing on the message digests usable for your ciphers.
> >
> > > so what you are asking Tomcat Connector to do is
> > >
> > > 1)export contents of supplied keystoreFile key of keystoreType
> > > PKCS12
> > >
> > > 2)determine Signature algorithm name
> > >
> > > 3)aggregate cipherSuite by determining Signature specific supported
> > > ciphers from Signature algorithm name from
> > > http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERef
> > > Guide.html
> > >
> > >
> > >
> > 4)reference ciphers attribute from Tomcat <Connector
> > >
> > > 5)determine SignatureSpecificSupportedCiphers from 3) and implement
> > > ONLY those ciphers which match exactly to the ciphers listed in
> > > Tomcat Connector 5)
> >
> > None of the previous 5 items is accurate.
> >
> > > (i have not seen this currently implemented)
> >
> > That's because Tomcat does something else. Actually, JSSE does all the
> > heavy-lifting: Tomcat just configures the TrustStore and a few other
> > things and then lets JSSE take over. Or OpenSSL if you're using
> > APR/native.
> >
> > Now, if you've had enough, kindly stop confusing people.
> >
> > - -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/
> >
> > iEYEAREIAAYFAlDvTc4ACgkQ9CaO5/Lv0PC70gCgqL83yS3LxAqhS+eAFi1StwPU
> > J5kAoMPWqUx/qnoB8gBla4gkRSWbpswO
> > =W6U2
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
