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.
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. 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. If the client certificate isn't one of those types or isn't signed by one of those signers, it isn't sent, and if the Web resource being requested is defined as requiring SSL client authentication, Tomcat would then deny access. Connection between (1) and (2): zero. 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
