Re: Restricting ciphers
As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA The BIO connector in = 7.0.35 silently reverts to the JVM default ciphers (and sslEnabledProtocols) if none of the specified options are supported by the SSL implemenation. I've changed this in 7.0.36+ [1] to not do this (I've had customers bitten by the same issue when running on AIX, since IBM change the prefix on all the cipher suites from TLS_ to SSL_). [1]: https://issues.apache.org/bugzilla/show_bug.cgi?id=54406 cheers tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/10/13 10:35 PM, Martin Gainty wrote: 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 Supported ciphers may be set in the connector without regard to any details of the server's X509 key or the certificate created with it. You can have an RSA key and still support RC4-SHA as one of your ciphers. Likewise, you can use a DSA key (for which OpenSSL always uses MD5 as the signature algorithm) with ciphers that use SHA1 as the signature algorithm. Keys/certs and ciphers are entirely orthogonal in the algorithms they support. SSL uses asymmetric encryption to exchange symmetric cipher keys using any cipher upon which the server and client can agree. Those ciphers are not limited by anything in the server's certificate or key. please dont waste my time and anyone elses with insults when you are unable to answer this simple question I have answered it above. If you disagree with my answer, please be specific. - -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/ iEYEAREIAAYFAlDwNQYACgkQ9CaO5/Lv0PATEQCgo3LI5SbHiChoPJRgT1kKHDAO ZyMAoJdz9eMl8xRXhvDEfIOfOITTbLHi =f/P3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/10/13 11:00 PM, Martin Gainty wrote: http://security.stackexchange.com/questions/7440/what-ciphers-should-i-use-in-my-web-server-after-i-configure-my-ssl-certificate With a RSA 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. With a DSA key you can use only a DHE_DSS cipher suite. With a Diffie-Hellman key, you can use only one of DH_RSA or DH_DSS, depending on the issuing certificate authority key type. your witness My certificate technical details: Signature Algorithm: sha1WithRSAEncryption Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) $ sslscan [myhost] | grep Accepted Accepted SSLv3 256 bits DHE-RSA-AES256-SHA Accepted SSLv3 256 bits AES256-SHA Accepted SSLv3 128 bits DHE-RSA-AES128-SHA Accepted SSLv3 128 bits AES128-SHA Accepted SSLv3 168 bits EDH-RSA-DES-CBC3-SHA Accepted SSLv3 168 bits DES-CBC3-SHA Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted TLSv1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1 256 bits AES256-SHA Accepted TLSv1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1 128 bits AES128-SHA Accepted TLSv1 168 bits EDH-RSA-DES-CBC3-SHA Accepted TLSv1 168 bits DES-CBC3-SHA Accepted TLSv1 128 bits RC4-SHA Accepted TLSv1 128 bits RC4-MD5 So, my server with a 2048-bit RSA key with SHA1 signature will accept all kinds of key exchange schemes (DHE, EDH, etc.), all kinds of block ciphers (AES, DES, 3DES, RC4), and all kinds of MAC algorithms (SHA1, MD5). Your assertion that somehow I'm limited to RSA + SHA1 + some weird selection of ciphers that are bound to my key or certificate's technical details is simply false. - -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/ iEYEAREIAAYFAlDwONUACgkQ9CaO5/Lv0PAZhQCgiwg9ooMWXN8rmu9dCvbyyFrF SEAAn1GXVnWi37S13DXUY7HNMntBvuYl =8whg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting ciphers
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
RE: Restricting ciphers
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. MGunderstood
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.
MGyes 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.
MGthus the choice for cipher suites is now assigned
MGreprising the publicKey signer algorithm to cipher suite
MGWith 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.
MGWith a DSA (public) key you can use only a DHE_DSS cipher suite.
MGWith 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 MGthe choice is made! and if the Web
resource being requested is defined
as requiring SSL client authentication, Tomcat would then deny access.
MGlets look at the guts of a public key to clarify whats going on MGkeytool
-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=99, EMAILADDRESS=paynom...@paynomind.com, CN=BigBank,
OU=, O=BigBank.com
Issuer: UID=IssuingAuthority, CN=CanonicalName, OU=IT Security, O=CanonicalName
Serial number:
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=99, CN=CanonicalName ID: 99, OU=, O=paynomind.com
Signature Algorithm: SHA1withRSA Key: Sun RSA public key, 2048 bits
modulus: Omitted public exponent: 9
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. MGagreed
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
Re: Restricting ciphers
-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. MGunderstood 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. MGyes 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. MGthus 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). MGreprising the publicKey signer algorithm to cipher suite Not relevant, whatever that means. MGWith 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. MGWith 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. MGWith 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 MGthe 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. MGlets look at the guts of a public key to clarify whats going on Let's. MGkeytool -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=99, EMAILADDRESS=paynom...@paynomind.com, CN=BigBank, OU=, O=BigBank.com Issuer: UID=IssuingAuthority, CN=CanonicalName, OU=IT Security, O=CanonicalName Serial number: 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
RE: Restricting ciphers
terminology : the X509 standard defines certificates, and RSA and DSA are two of the public key algorithms that can be used in those certificates; certificates are used to hold public keys, and never private keys. PKCS#12 is a standard for a container which holds an X509 client certificates and private keys So, if you're examining a PKCS#12 file (typically .p12 extension or a .pfx extension), then you already know: It contains at least one X509 client certificate and corresponding private keys. All you don't know is whether those certificate private key are RSA or DSA algorithms You can check this by extracting the certificate(s), and then examine them:openssl pkcs12 -in mycert.p12 -clcerts -nokeys -out mycert.crt openssl x509 -in mycert.crt -text The text output of the openssl x509 command should include a Subject Public Key section, which will include fields that let you see if it's an RSA or DSA key (along with the key size). http://stackoverflow.com/questions/1722181/determine-certificate-type PublicKey Generation: to generate a public-key from PKCS12 privateKeyAndX509Cert use openssl openssl pkcs12 -in myFile.p12 -out myPublicKey.pem -clcerts -nokeys https://ca.cern.ch/ca/Help/?kbid=023010 KeyAlgorithms: KeyAlgorithms are categorised to their cipher-groups symmetric ciphers, public-key ciphers, and one-way hashing to list available ciphers within AES algorithm use openssl e.g. openssl ciphers -v 'AES+HIGH' cipherGroup is categorised by keysize within cipher-groups (usually a 4digit number which is a power of 2 e.g. 1024 and 2048) http://www.gnupg.org/gph/en/manual.html#AEN185 each permutation of cipherGroup-KeySize is further categorised according to implemented ModeOfOperation http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation 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: 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: http://docs.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html 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/JSSERefGuide.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) (i have not seen this currently implemented) Martin __ do not alter or disrupt this transmission Date: Thu, 10 Jan 2013 11:44:49 +0400 Subject: Re: Restricting ciphers From: knst.koli...@gmail.com To: users@tomcat.apache.org 2013/1/10 Baron Fujimoto ba...@hawaii.edu: On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: 2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / (...) As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA
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/JSSERefGuide.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
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/JSSERefGuide.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
RE: Restricting ciphers
http://security.stackexchange.com/questions/7440/what-ciphers-should-i-use-in-my-web-server-after-i-configure-my-ssl-certificate With a RSA 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. With a DSA key you can use only a DHE_DSS cipher suite. With a Diffie-Hellman key, you can use only one of DH_RSA or DH_DSS, depending on the issuing certificate authority key type. your witness Martin __ From: mgai...@hotmail.com To: users@tomcat.apache.org Subject: RE: Restricting ciphers Date: Thu, 10 Jan 2013 22:35:05 -0500 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/JSSERefGuide.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
Re: Restricting ciphers
2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / However, when I test this by attempting connections with a script[*] that iterates through the set of ciphers available to openssl, it appears to successfully connect with the following set of ciphers: AES128-SHA DES-CBC-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-RC4-MD5 EXP-RC4-MD5 RC4-MD5 RC4-MD5 RC4-SHA [*] The script basically parses the output of the following command: openssl s_client -cipher $cipher -connect $SERVER Am I misunderstanding the use of the ciphers parameter? Or is there perhaps something in my testing methodology that accounts for these unexpected results? Any advice would be appreciated. As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting ciphers
Baron org.apache.catalina.connector.Connector: public void setProtocol(String
protocol) {if (AprLifecycleListener.isAprAvailable()) {
if (HTTP/1.1.equals(protocol)) {
setProtocolHandlerClassName
(org.apache.coyote.http11.Http11AprProtocol);
} else if (AJP/1.3.equals(protocol)) {
setProtocolHandlerClassName
(org.apache.coyote.ajp.AjpAprProtocol);
} else if (protocol != null) {
setProtocolHandlerClassName(protocol);
} else {
setProtocolHandlerClassName
(org.apache.coyote.http11.Http11AprProtocol);
}
} else {
if (HTTP/1.1.equals(protocol)) {
setProtocolHandlerClassName
(org.apache.coyote.http11.Http11Protocol);
} else if (AJP/1.3.equals(protocol)) {
setProtocolHandlerClassName
(org.apache.coyote.ajp.AjpProtocol);
} else if (protocol != null) {
setProtocolHandlerClassName(protocol);
}
}}
setProtocol assigns
protocolHandlerClassName=org.apache.coyote.http11.Http11AprProtocol public
Connector(String protocol) {
setProtocol(protocol);
// Instantiate protocol handler
try {
Class? clazz = Class.forName(protocolHandlerClassName);
this.protocolHandler = (ProtocolHandler) clazz.newInstance();
} catch (Exception e) {
log.error
(sm.getString
(coyoteConnector.protocolHandlerInstantiationFailed, e));
}
}
/*** Return a configured property. */
public Object getProperty(String name) {
String repl = name;
if (replacements.get(name) != null) {
repl = replacements.get(name);
}
return IntrospectionUtils.getProperty(protocolHandler, repl);
} org.apache.tomcat.util.IntrospectionUtils
public static Object getProperty(Object o, String name) {
String getter = get + capitalize(name);
String isGetter = is + capitalize(name);try {
Method methods[] = findMethods(o.getClass());
Method getPropertyMethod = null;// First, the ideal
case - a getFoo() method
for (int i = 0; i methods.length; i++) {
Class? paramT[] = methods[i].getParameterTypes();
if (getter.equals(methods[i].getName()) paramT.length == 0) {
return methods[i].invoke(o, (Object[]) null);/snip
org.apache.coyote.http11.Http11AprProtocol public void init() throws Exception {
endpoint.setName(getName());public String getName() {
String encodedAddr = ;
if (getAddress() != null) {
encodedAddr = + getAddress();
if (encodedAddr.startsWith(/))
encodedAddr = encodedAddr.substring(1);
encodedAddr = URLEncoder.encode(encodedAddr) + -;
}
return (http- + encodedAddr + endpoint.getPort());
} return the SSLCipherSuite() for the specified endpoint
public String getSSLCipherSuite() { return endpoint.getSSLCipherSuite(); }
(assume Endpoint is Apr and Not Nio or Jio)
org.apache.tomcat.util.net.AprEndpoint protected String SSLCipherSuite = ALL;
public String getSSLCipherSuite() { return SSLCipherSuite; }
public void setSSLCipherSuite(String SSLCipherSuite) { this.SSLCipherSuite
= SSLCipherSuite; }
you found a bug!
Martin Gainty
__
We have awaken a sleeping bear and filled him with a terrible resolve...Admiral
Yamamoto...7 December 1941 Date: Tue, 8 Jan 2013 16:55:02 -1000
From: ba...@hawaii.edu
To: users@tomcat.apache.org
Subject: Restricting ciphers
I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35.
My understanding is that the attack applies only to CBC ciphers, and that
RC4 ciphers are not vulnerable, so I am attempting to restrict the set of
ciphers that Tomcat uses with the following config for a connector:
Connector protocol=HTTP/1.1 SSLEnabled=true
address=0.0.0.0
port=8443
maxThreads=150 scheme=https secure=true
keystoreFile=/path/to/keystore
keystoreType=pkcs12
ciphers=TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_RC4_128_MD5,
SSL_CK_RC4_128_WITH_MD5
clientAuth=false sslProtocol=TLS /
However, when I test this by attempting connections with a script[*] that
iterates through the set of ciphers available to openssl, it appears to
successfully connect with the following set of ciphers:
AES128-SHA
DES-CBC-SHA
DES-CBC3-SHA
DHE-RSA-AES128-SHA
EDH-RSA-DES-CBC-SHA
EDH-RSA-DES-CBC3-SHA
EXP-DES-CBC-SHA
EXP-EDH-RSA-DES-CBC-SHA
EXP-RC4-MD5
EXP-RC4-MD5
RC4-MD5
RC4-MD5
RC4-SHA
[*] The script basically parses the
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Baron, On 1/8/13 9:55 PM, Baron Fujimoto wrote: However, when I test this by attempting connections with a script[*] You could use 'sslscan' which is available directly from many Linux package managers. You can also use online tools like Qualys's scanner[1], which tells you which vulnerabilities you might have such as BEAST, CRIME, client-renegotiation, etc. Worth mentioning: I'm not sure how to do such a thing with the JSSE SSL implementation, but if you use APR/native with OpenSSL, you want to enable the honor server cipher order flag. Unfortunately, this won't work quite properly with Tomcat right now due to a series of prerequisites that need to fall into place for it to work correctly ([2] and [3]). - -chris [1] https://www.ssllabs.com/ssltest/index.html [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=53481 [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=53969 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDthjcACgkQ9CaO5/Lv0PDrpwCgr19iDh6kKGKN7jjM6WmkfZFe xH0AniNsKyyjYQnivoCPJmw+koye3AXS =jvUJ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Martin,
On 1/9/13 8:33 AM, Martin Gainty wrote:
org.apache.tomcat.util.net.AprEndpoint protected String
SSLCipherSuite = ALL; public String getSSLCipherSuite() { return
SSLCipherSuite; } public void setSSLCipherSuite(String
SSLCipherSuite) { this.SSLCipherSuite = SSLCipherSuite; }
you found a bug!
Care to explain?
- -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/
iEYEAREIAAYFAlDtiekACgkQ9CaO5/Lv0PAspACgiBnVeX38JypmG5ESGZvlGAiV
EWEAoKs6JEIcs4rYf0jx4YmNn3pnZ+ai
=feQa
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: 2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / However, when I test this by attempting connections with a script[*] that iterates through the set of ciphers available to openssl, it appears to successfully connect with the following set of ciphers: AES128-SHA DES-CBC-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-RC4-MD5 EXP-RC4-MD5 RC4-MD5 RC4-MD5 RC4-SHA [*] The script basically parses the output of the following command: openssl s_client -cipher $cipher -connect $SERVER Am I misunderstanding the use of the ciphers parameter? Or is there perhaps something in my testing methodology that accounts for these unexpected results? Any advice would be appreciated. As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Restricting ciphers
how does one divine EPR change from APR to AJP or NIO based on keystoreType? if we use curl --key-type type Private key file type (DER/PEM/ENG) there is NO relationship to EPR implementation because there is no EPR curl is implementing what does keystoreType have to do with the choice of EPR ? explain this algorithm please Martin __ do not alter this email communication Date: Wed, 9 Jan 2013 12:22:27 -1000 From: ba...@hawaii.edu To: users@tomcat.apache.org Subject: Re: Restricting ciphers On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: 2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / However, when I test this by attempting connections with a script[*] that iterates through the set of ciphers available to openssl, it appears to successfully connect with the following set of ciphers: AES128-SHA DES-CBC-SHA DES-CBC3-SHA DHE-RSA-AES128-SHA EDH-RSA-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA EXP-DES-CBC-SHA EXP-EDH-RSA-DES-CBC-SHA EXP-RC4-MD5 EXP-RC4-MD5 RC4-MD5 RC4-MD5 RC4-SHA [*] The script basically parses the output of the following command: openssl s_client -cipher $cipher -connect $SERVER Am I misunderstanding the use of the ciphers parameter? Or is there perhaps something in my testing methodology that accounts for these unexpected results? Any advice would be appreciated. As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA -baron -- Baron Fujimoto ba...@hawaii.edu :: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum desendus pantorum - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Baron, On 1/9/13 5:22 PM, Baron Fujimoto wrote: On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. It's odd that JSSE ended up being seeded with anything but an empty list of ciphers. I would expect that if you said ciphers=BOGUS_CIPHER then no connections would be possible. But you were able to start the connection and make connections even with all those broken cipher names, right? - -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/ iEYEAREIAAYFAlDuNpEACgkQ9CaO5/Lv0PDYTACeN6kRlIwtmTaguRNfHdvyljpX kRwAnRc+uNPAsPi9K94DE/h7xOT5DnFp =w2ms -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 1/9/13 6:27 PM, Martin Gainty wrote: how does one divine EPR change from APR to AJP or NIO based on keystoreType? Great, now /you/ are in on the quantum mechanics jokes around here? *sigh* if we use curl --key-type type Private key file type (DER/PEM/ENG) there is NO relationship to EPR implementation because there is no EPR curl is implementing what does keystoreType have to do with the choice of EPR ? explain this algorithm please What in the world are you talking about? - -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/ iEYEAREIAAYFAlDuNukACgkQ9CaO5/Lv0PD3GgCfcfwqQUuuNsnSRjecSedixPip Yz0An3c1B06ZA05jhVWcK6Nqi2jirexg =IrGB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Restricting ciphers
2013/1/10 Baron Fujimoto ba...@hawaii.edu: On Wed, Jan 09, 2013 at 01:08:01PM +0400, Konstantin Kolinko wrote: 2013/1/9 Baron Fujimoto ba...@hawaii.edu: I'm attempting to mitigate BEAST (CVE-2011-3389) attacks on Tomcat 6.0.35. My understanding is that the attack applies only to CBC ciphers, and that RC4 ciphers are not vulnerable, so I am attempting to restrict the set of ciphers that Tomcat uses with the following config for a connector: Connector protocol=HTTP/1.1 SSLEnabled=true address=0.0.0.0 port=8443 maxThreads=150 scheme=https secure=true keystoreFile=/path/to/keystore keystoreType=pkcs12 ciphers=TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, SSL_CK_RC4_128_WITH_MD5 clientAuth=false sslProtocol=TLS / (...) As can be seen from your usage of keystoreType attribute, you are using Java implementation of the Connector, not openssl/APR one. You should look into Java documentation for their cipher names. See this thread from October 2009: http://markmail.org/message/zn4namfhypyxum23 Ahh, that was it! It did not occur to me that OpenSSL and Java might name the ciphers differently. If I restrict the ciphers to those from the (differently named) set used by Java, it works as expected. Mahalo! ciphers=SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA Good. I used your example to create a FAQ page, http://wiki.apache.org/tomcat/HowTo/SSLCiphers Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
