tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Gainty <mgai...@hotmail.com>
Subject RE: Restricting ciphers
Date Sat, 12 Jan 2013 02:26:13 GMT


  > 
> 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=paynomind@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:mgainty@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: chris@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > 
>  		 	   		  
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message