Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #34143 > unrolled thread

One for the encryption experts

Started byDuncan Idaho <duncan@dunenoemail.com>
First post2016-04-15 16:23 +0100
Last post2016-04-16 17:42 +0100
Articles 6 — 3 participants

Back to article view | Back to comp.lang.java.programmer

Contents

  One for the encryption experts Duncan Idaho <duncan@dunenoemail.com> - 2016-04-15 16:23 +0100
    Re: One for the encryption experts Robert Klemme <shortcutter@googlemail.com> - 2016-04-16 11:49 +0200
      Re: One for the encryption experts Nemo <nemo@invalid.invalid> - 2016-04-16 08:44 -0400
        Re: One for the encryption experts Duncan Idaho <duncan@dunenoemail.com> - 2016-04-16 16:03 +0100
          Re: One for the encryption experts Robert Klemme <shortcutter@googlemail.com> - 2016-04-16 17:13 +0200
            Re: One for the encryption experts Duncan Idaho <duncan@dunenoemail.com> - 2016-04-16 17:42 +0100

#34143 — One for the encryption experts

FromDuncan Idaho <duncan@dunenoemail.com>
Date2016-04-15 16:23 +0100
SubjectOne for the encryption experts
Message-ID<ner0r1$7j1$1@dont-email.me>
Hi

The Question is:

Am I going insane,and, if not, does anyone have any idea how to fix the 
problem described below.

(I'm also going to post this to the Tomcat list)

Let me say straight away I am no cipher/encryption expert, I'm not even 
sure I'm using the right terminology but here goes anyway.

I have an ssl certificate installed for apache-tomcat-7.0.42 running  as 
a standalone web server on port 80, it's been this way for the past 
three years and it does fine although I've only just got the cert.

It all works apart from the key exchange which the Chrome browser 
bitches about. It tells me that the server uses RSA as the key exchange 
mechanism and it's not happy about that.

It used to run under Java 1.7.0_45 but in an attempt to fix problems 
with the key exchange cipher suite I now have it running under
Java 1.8.0_77-b03. The processor architecture is i586 and tomcat is 
hosted on CentOS by a large hosting company.

The cipher it should use is ECDHE_RSA, I know this because I have the 
same version of Tomcat using the same version of Java 1.8.0_77-b03 but 
for the x64 processor architecture on my home network running on Ubuntu 
Linux, Chrome is quite happy with this cipher apparently.

The really bizarre thing is that ECDHE ciphers are available for the x64 
architecture but not for the i586 architecture. Is this really the case 
or am I actually going insane.

Thanks and mind you don't damage your brain reading the following.
That's all I have to say, the rest of this message is geek soup.

Oh yes

I found a small Java program online that prints out the default cipher 
suits for a given Java installation. I believe it's been written by one 
of the guys from the Tomcat mailing list. I've tacked the code on at the 
end. First the remote server, no ECHDE ciphers in either distro

jdk1.7.0_45_i586

Default	Cipher
  	SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_DSS_WITH_DES_CBC_SHA
  	SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_RSA_WITH_DES_CBC_SHA
  	SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
  	SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
  	SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
  	SSL_DH_anon_WITH_DES_CBC_SHA
  	SSL_DH_anon_WITH_RC4_128_MD5
  	SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
  	SSL_RSA_EXPORT_WITH_RC4_40_MD5
*	SSL_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_RSA_WITH_DES_CBC_SHA
  	SSL_RSA_WITH_NULL_MD5
  	SSL_RSA_WITH_NULL_SHA
*	SSL_RSA_WITH_RC4_128_MD5
*	SSL_RSA_WITH_RC4_128_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  	TLS_DH_anon_WITH_AES_128_CBC_SHA
  	TLS_DH_anon_WITH_AES_128_CBC_SHA256
*	TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
  	TLS_KRB5_EXPORT_WITH_RC4_40_MD5
  	TLS_KRB5_EXPORT_WITH_RC4_40_SHA
  	TLS_KRB5_WITH_3DES_EDE_CBC_MD5
  	TLS_KRB5_WITH_3DES_EDE_CBC_SHA
  	TLS_KRB5_WITH_DES_CBC_MD5
  	TLS_KRB5_WITH_DES_CBC_SHA
  	TLS_KRB5_WITH_RC4_128_MD5
  	TLS_KRB5_WITH_RC4_128_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA256
  	TLS_RSA_WITH_NULL_SHA256

jdk1.8.0_77_i586

Default	Cipher
  	SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_DSS_WITH_DES_CBC_SHA
  	SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_RSA_WITH_DES_CBC_SHA
  	SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
  	SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
  	SSL_DH_anon_WITH_DES_CBC_SHA
  	SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
*	SSL_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_RSA_WITH_DES_CBC_SHA
  	SSL_RSA_WITH_NULL_MD5
  	SSL_RSA_WITH_NULL_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*	TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  	TLS_DH_anon_WITH_AES_128_CBC_SHA
  	TLS_DH_anon_WITH_AES_128_CBC_SHA256
  	TLS_DH_anon_WITH_AES_128_GCM_SHA256
*	TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
  	TLS_KRB5_WITH_3DES_EDE_CBC_MD5
  	TLS_KRB5_WITH_3DES_EDE_CBC_SHA
  	TLS_KRB5_WITH_DES_CBC_MD5
  	TLS_KRB5_WITH_DES_CBC_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA256
*	TLS_RSA_WITH_AES_128_GCM_SHA256
  	TLS_RSA_WITH_NULL_SHA256


My home network with exactly the same release but for the x64 processor 
architecture

jdk1.8.0_77_x64 with ECHDE

Default	Cipher
  	SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_DSS_WITH_DES_CBC_SHA
  	SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
*	SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_DHE_RSA_WITH_DES_CBC_SHA
  	SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
  	SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
  	SSL_DH_anon_WITH_DES_CBC_SHA
  	SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
*	SSL_RSA_WITH_3DES_EDE_CBC_SHA
  	SSL_RSA_WITH_DES_CBC_SHA
  	SSL_RSA_WITH_NULL_MD5
  	SSL_RSA_WITH_NULL_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
*	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
*	TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
*	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
*	TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  	TLS_DH_anon_WITH_AES_128_CBC_SHA
  	TLS_DH_anon_WITH_AES_128_CBC_SHA256
  	TLS_DH_anon_WITH_AES_128_GCM_SHA256
*	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
*	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
*	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
*	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  	TLS_ECDHE_ECDSA_WITH_NULL_SHA
*	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
*	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
*	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
*	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  	TLS_ECDHE_RSA_WITH_NULL_SHA
*	TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
*	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
*	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
*	TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
  	TLS_ECDH_ECDSA_WITH_NULL_SHA
*	TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
*	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
*	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
*	TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
  	TLS_ECDH_RSA_WITH_NULL_SHA
  	TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
  	TLS_ECDH_anon_WITH_AES_128_CBC_SHA
  	TLS_ECDH_anon_WITH_NULL_SHA
*	TLS_EMPTY_RENEGOTIATION_INFO_SCSV
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
  	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
  	TLS_KRB5_WITH_3DES_EDE_CBC_MD5
  	TLS_KRB5_WITH_3DES_EDE_CBC_SHA
  	TLS_KRB5_WITH_DES_CBC_MD5
  	TLS_KRB5_WITH_DES_CBC_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA
*	TLS_RSA_WITH_AES_128_CBC_SHA256
*	TLS_RSA_WITH_AES_128_GCM_SHA256
  	TLS_RSA_WITH_NULL_SHA256



=================== code ==================

import java.util.Iterator;
import java.util.Map;
import java.util.TreeMap; import javax.net.ssl.SSLServerSocketFactory;

public class SSLInfo { public static void main(String[] args) throws
Exception { SSLServerSocketFactory ssf =
(SSLServerSocketFactory)SSLServerSocketFactory.getDefault();

String[] defaultCiphers = ssf.getDefaultCipherSuites(); String[]
availableCiphers = ssf.getSupportedCipherSuites();

TreeMap ciphers = new TreeMap();

for(int i=0; i<availableCiphers.length; ++i )
ciphers.put(availableCiphers[i], Boolean.FALSE);

for(int i=0; i<defaultCiphers.length; ++i )
ciphers.put(defaultCiphers[i], Boolean.TRUE);

System.out.println("Default\tCipher"); for(Iterator i =
ciphers.entrySet().iterator(); i.hasNext(); ) { Map.Entry
cipher=(Map.Entry)i.next();

if(Boolean.TRUE.equals(cipher.getValue())) System.out.print('*'); else
System.out.print(' ');

System.out.print('\t'); System.out.println(cipher.getKey()); } } }


-- 
Duncan Idaho

[toc] | [next] | [standalone]

#34150

FromRobert Klemme <shortcutter@googlemail.com>
Date2016-04-16 11:49 +0200
Message-ID<dneg5uFl25pU1@mid.individual.net>
In reply to#34143
On 15.04.2016 17:23, Duncan Idaho wrote:

> The Question is:
>
> Am I going insane,and, if not, does anyone have any idea how to fix the
> problem described below.

Just to exclude one obvious item: are you using Apache Native library on 
any of the two deployments by any chance?

> It all works apart from the key exchange which the Chrome browser
> bitches about. It tells me that the server uses RSA as the key exchange
> mechanism and it's not happy about that.
>
> It used to run under Java 1.7.0_45 but in an attempt to fix problems
> with the key exchange cipher suite I now have it running under
> Java 1.8.0_77-b03. The processor architecture is i586 and tomcat is
> hosted on CentOS by a large hosting company.

32 bit architecture for a server?  That seems odd these days.

> The cipher it should use is ECDHE_RSA, I know this because I have the
> same version of Tomcat using the same version of Java 1.8.0_77-b03 but
> for the x64 processor architecture on my home network running on Ubuntu
> Linux, Chrome is quite happy with this cipher apparently.

I would test with openssl with verbose output switched on to see and 
understand what is going on during the handshake.

> The really bizarre thing is that ECDHE ciphers are available for the x64
> architecture but not for the i586 architecture. Is this really the case
> or am I actually going insane.

It could also be different configurations.  I am not an expert for SSL 
either but I would check with openssl to get an idea what is used.  Then 
I'd check configurations.  I seem to remember that some ciphers might 
not be available in some Java packages because of export regulation.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#34152

FromNemo <nemo@invalid.invalid>
Date2016-04-16 08:44 -0400
Message-ID<atqQy.6483$3C3.2611@fx03.iad>
In reply to#34150
On 16/04/2016 05:49, Robert Klemme wrote:
> On 15.04.2016 17:23, Duncan Idaho wrote:
>> [../] tomcat is hosted on CentOS by a large hosting company.
[...]
> It could also be different configurations. I am not an expert for SSL
> either but I would check with openssl to get an idea what is used. Then
> I'd check configurations. I seem to remember that some ciphers might not
> be available in some Java packages because of export regulation.

Older versions of CentOS shipped with OpenSSL built without ECC.  I 
concur in checking what suites are supported on the server.  (Something 
such as "openssl ciphers" should give you the list.)

N.

[toc] | [prev] | [next] | [standalone]

#34153

FromDuncan Idaho <duncan@dunenoemail.com>
Date2016-04-16 16:03 +0100
Message-ID<netk2i$9k0$1@dont-email.me>
In reply to#34152
On 16/04/16 13:44, Nemo wrote:
> On 16/04/2016 05:49, Robert Klemme wrote:
>> On 15.04.2016 17:23, Duncan Idaho wrote:
>>> [../] tomcat is hosted on CentOS by a large hosting company.
> [...]
>> It could also be different configurations. I am not an expert for SSL
>> either but I would check with openssl to get an idea what is used. Then
>> I'd check configurations. I seem to remember that some ciphers might not
>> be available in some Java packages because of export regulation.
>
> Older versions of CentOS shipped with OpenSSL built without ECC.  I
> concur in checking what suites are supported on the server.  (Something
> such as "openssl ciphers" should give you the list.)
>
> N.

Thanks for your help

Something Robert said jogged the old gray matter (old being the 
operative word)

I was in a hurry to get the server up so I just copied an old setup I 
had and it worked, now don't shout at me but ...

I run Tomcat on port 80 using jsvc 
(https://commons.apache.org/proper/commons-daemon/). I agree that the 
requirement for the i586 package should have rung a bell but it didn't, 
so I compiled jsvc on a 64 bit Linux box on my home network passing the 
x64 Java to the compiler, copied the new jsvc to the remote server, 
updated tomcat.service,  systemctl daemon-reload, systemctl start 
tomcat.service and bingo,
tomcat 7 runs against 64 bit vm and Chrome doesn't barf any more, modern 
cipher suits.

Serves me right for trying to take shortcuts.

ssl labs still only gives me a B, something about weak diffie-helman key 
exchanges but hopefully I can sleep nights again.

Y'know what, I've been trying to track this down for a while now and 
once again only c.l.j.p really helped.

Thanks for that, my sanity is safe (for a while anyway)

Duncan

-- 
Duncan Idaho

[toc] | [prev] | [next] | [standalone]

#34154

FromRobert Klemme <shortcutter@googlemail.com>
Date2016-04-16 17:13 +0200
Message-ID<dnf344FppnqU1@mid.individual.net>
In reply to#34153
On 16.04.2016 17:03, Duncan Idaho wrote:

> Something Robert said jogged the old gray matter (old being the
> operative word)

:-))

> Serves me right for trying to take shortcuts.

Well, that is often what happens: you save time now and pay later. :-)

> ssl labs still only gives me a B, something about weak diffie-helman key
> exchanges but hopefully I can sleep nights again.

You could completely disable DH or try to set a min key length of 2k or 
more.  IIRC only disabling is possible in Java.

> Y'know what, I've been trying to track this down for a while now and
> once again only c.l.j.p really helped.
>
> Thanks for that, my sanity is safe (for a while anyway)

You're welcome!

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#34155

FromDuncan Idaho <duncan@dunenoemail.com>
Date2016-04-16 17:42 +0100
Message-ID<netprk$41n$1@dont-email.me>
In reply to#34154
On 16/04/16 16:13, Robert Klemme wrote:
> On 16.04.2016 17:03, Duncan Idaho wrote:
>
>> Something Robert said jogged the old gray matter (old being the
>> operative word)
>
> :-))
>
>> Serves me right for trying to take shortcuts.
>
> Well, that is often what happens: you save time now and pay later. :-)
>
>> ssl labs still only gives me a B, something about weak diffie-helman key
>> exchanges but hopefully I can sleep nights again.
>
> You could completely disable DH or try to set a min key length of 2k or
> more.  IIRC only disabling is possible in Java.

This does it

https://support.comodo.com/index.php?/Default/Knowledgebase/Article/View/659/17/how-to----disable-weak-ciphers-in-tomcat-7--8

An 'A' from ssllabs.com

I'm off for several beers, there's one in the tap for you guys.

Happy days

Duncan

-- 
Duncan Idaho

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web