You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Baron Fujimoto <ba...@hawaii.edu> on 2013/01/09 03:55:02 UTC
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 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.
Aloha,
-baron
--
Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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: baron@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 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.
>
> Aloha,
> -baron
> --
> Baron Fujimoto <ba...@hawaii.edu> :: UH Information Technology Services
> minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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=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
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
>
> 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
>
RE: Restricting ciphers
Posted by Esmond Pitt <es...@bigpond.com>.
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: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
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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: mgainty@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: 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/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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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/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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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.kolinko@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,
> > 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Restricting ciphers
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Restricting ciphers
Posted by Martin Gainty <mg...@hotmail.com>.
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: baron@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by Tim Whittington <ti...@apache.org>.
>>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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by 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" />
>>
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Restricting ciphers
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org