Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
ECDHE-ECDSA Support
206 views
Skip to first unread message
Thomas Montroy
Mar 26, 2014, 4:14:05 PM3/26/14
to
hi All,
I've been trying to make ECDHE-ECDSA connections with openssl and have been having trouble.
openssl s_client -connect mail.google.com:443 -tls1_2
This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256
According to Google-Chrome, the cipher for my web-based gmail connection should be:
ECDHE-ECDSA-AES128-GCM-SHA256
If I try to make that connection
openssl s_client -connect mail.google.com:443 -tls1_2 -cipher ECDHE-ECDSA-AES128-GCM-SHA256
I get:
CONNECTED(00000003)
139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1440:SSL alert number 40
139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:617:
which looks like no connection.
I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any case.
I downloaded and compiled the latest version of gnutls:
This gives an ECDHE-ECDSA connection
gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com
This gives an ECDHE-RSA
gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-RSA mail.google.com
So I'm able to see both types of certificates for mail.google.com with gnutls.
Any ideas why I can't do that with openssl?
Cheers,
-Tom
Jeffrey Walton
Mar 26, 2014, 6:43:30 PM3/26/14
to
> I'm running ubuntu (12.04, I think) on a VM on a Macbook Air using VMware. I
> tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any
> case.
> ...
> tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no luck in any
> case.
> Any ideas why I can't do that with openssl?
Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for
example, OpenSSL downlevel version is 1.0.0, and does not support TLS
1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576.
You should be able to connect with -tls1; or build/install OpenSSL
yourself and use the one installed at /usr/local/ssl/bin/openssl.
You can also use -CAfile option for s_client to avoid the verify
error. Use Google's Google Internet Authority G2 at
http://pki.google.com/.
Jeff
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Thomas Montroy
Mar 27, 2014, 8:40:08 AM3/27/14
to
hi Jeff,
Thanks for the response, but I'm still having trouble.
As for TLSv1.2:
With the OS version of openssl, my default connection looks to be TLSv1.1
However, if I add -tls1_2 to the call, I get this:
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Should this be consider accurate (or should I verify with wireshark?)?
I compiled the openssl-1.0.2-beta and it's default connections looks to be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA.
One interesting point is that mail.google.com has at least two certificates one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both certs with gnutls-cli.
I made a test certificate using ECDHE-ECDSA so I'm guessing that means the capability is compiled in.
Cheers,
-Tom
Dr. Stephen Henson
Mar 27, 2014, 9:22:32 AM3/27/14
to
On Thu, Mar 27, 2014, Thomas Montroy wrote:
> hi Jeff,
>
> Thanks for the response, but I'm still having trouble.
>
> As for TLSv1.2:
>
> With the OS version of openssl, my default connection looks to be TLSv1.1
>
> However, if I add -tls1_2 to the call, I get this:
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-GCM-SHA384
>
> Should this be consider accurate (or should I verify with wireshark?)?
>
> I compiled the openssl-1.0.2-beta and it's default connections looks to be
> TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA.
>
> One interesting point is that mail.google.com has at least two certificates
> one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to
> mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both
> certs with gnutls-cli.
>
> I made a test certificate using ECDHE-ECDSA so I'm guessing that means the
> capability is compiled in.
>
An interesting little puzzle. I reproduced your results and using Firefox I
> hi Jeff,
>
> Thanks for the response, but I'm still having trouble.
>
> As for TLSv1.2:
>
> With the OS version of openssl, my default connection looks to be TLSv1.1
>
> However, if I add -tls1_2 to the call, I get this:
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-GCM-SHA384
>
> Should this be consider accurate (or should I verify with wireshark?)?
>
> I compiled the openssl-1.0.2-beta and it's default connections looks to be
> TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA.
>
> One interesting point is that mail.google.com has at least two certificates
> one with ECDHE-RSA and one with ECDHE-ECDSA. When I connect to
> mail.google.com in the browser, I get ECDHE-ECDSA. I can also see both
> certs with gnutls-cli.
>
> I made a test certificate using ECDHE-ECDSA so I'm guessing that means the
> capability is compiled in.
>
can see the ECDSA certificate but OpenSSL chokes if you try to restrict the
handshake to just ECDSA.
After some head scratching I wondered if servername has anything to do with
it. OpenSSL doesn't send servername by default but some other applications
do. Adding servername like this:
openssl s_client -connect mail.google.com:443 -servername mail.google.com
does the trick and you then get:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
Thomas Montroy
Mar 27, 2014, 9:35:36 AM3/27/14
to
Nice catch. Thanks for looking into it.
Cheers,
-Tom
Dr. Stephen Henson
Mar 27, 2014, 9:41:40 AM3/27/14
to
yet. If OpenSSL is compiled with zlib support you also have to disable
compression using -no_comp.
Rob Stradling
Mar 27, 2014, 9:17:26 AM3/27/14
to
Hi Thomas.
I was told a while ago that Google's servers will only negotiate
ECDHE-ECDSA if the client i) sends the SNI extension and ii) does _not_
offer any compression methods.
IINM, s_client always offers zlib compression if zlib support is
compiled in. It'd be nice if there was a command line switch for
s_client to disable compression (by setting the SSL_OP_NO_COMPRESSION
option in the SSL context), but, currently, there isn't.
Try:
openssl s_client -connect sslanalyzer.comodoca.com:443
I expect you'll find that this connects using ECDHE-ECDSA-AES256-GCM-SHA384.
On 27/03/14 12:40, Thomas Montroy wrote:
> hi Jeff,
>
> Thanks for the response, but I'm still having trouble.
>
> As for TLSv1.2:
>
> With the OS version of openssl, my default connection looks to be TLSv1.1
>
> However, if I add -tls1_2 to the call, I get this:
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-GCM-SHA384
>
> Should this be consider accurate (or should I verify with wireshark?)?
>
> I compiled the openssl-1.0.2-beta and it's default connections looks to
> be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA.
>
> One interesting point is that mail.google.com <http://mail.google.com>
> <http://mail.google.com>
> <http://mail.google.com> with
> Automated List Manager majo...@openssl.org
> <mailto:majo...@openssl.org>
>
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
I was told a while ago that Google's servers will only negotiate
ECDHE-ECDSA if the client i) sends the SNI extension and ii) does _not_
offer any compression methods.
IINM, s_client always offers zlib compression if zlib support is
compiled in. It'd be nice if there was a command line switch for
s_client to disable compression (by setting the SSL_OP_NO_COMPRESSION
option in the SSL context), but, currently, there isn't.
Try:
openssl s_client -connect sslanalyzer.comodoca.com:443
I expect you'll find that this connects using ECDHE-ECDSA-AES256-GCM-SHA384.
On 27/03/14 12:40, Thomas Montroy wrote:
> hi Jeff,
>
> Thanks for the response, but I'm still having trouble.
>
> As for TLSv1.2:
>
> With the OS version of openssl, my default connection looks to be TLSv1.1
>
> However, if I add -tls1_2 to the call, I get this:
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-GCM-SHA384
>
> Should this be consider accurate (or should I verify with wireshark?)?
>
> I compiled the openssl-1.0.2-beta and it's default connections looks to
> be TLSv1.2 However, I still fail to connect with any ECDHE-ECDSA.
>
> has at least two certificates one with ECDHE-RSA and one with
> ECDHE-ECDSA. When I connect to mail.google.com <http://mail.google.com>
> in the browser, I get ECDHE-ECDSA. I can also see both certs with
> gnutls-cli.
>
> I made a test certificate using ECDHE-ECDSA so I'm guessing that means
> the capability is compiled in.
>
> gnutls-cli.
>
> I made a test certificate using ECDHE-ECDSA so I'm guessing that means
> the capability is compiled in.
>
> Cheers,
>
> -Tom
>
>
>
>
>
>
>
>
> On Wed, Mar 26, 2014 at 6:43 PM, Jeffrey Walton <nolo...@gmail.com
> <mailto:nolo...@gmail.com>> wrote:
>
> > I'm running ubuntu (12.04, I think) on a VM on a Macbook Air
> using VMware. I
> > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no
> luck in any
> > case.
> > ...
> > Any ideas why I can't do that with openssl?
>
> Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for
> example, OpenSSL downlevel version is 1.0.0, and does not support TLS
> 1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576.
>
> You should be able to connect with -tls1; or build/install OpenSSL
> yourself and use the one installed at /usr/local/ssl/bin/openssl.
>
>
> -Tom
>
>
>
>
>
>
>
>
> On Wed, Mar 26, 2014 at 6:43 PM, Jeffrey Walton <nolo...@gmail.com
> <mailto:nolo...@gmail.com>> wrote:
>
> > I'm running ubuntu (12.04, I think) on a VM on a Macbook Air
> using VMware. I
> > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no
> luck in any
> > case.
> > ...
> > Any ideas why I can't do that with openssl?
>
> Ubuntu disables TLS 1.1 and 1.2 in their version of OpenSSL. See, for
> example, OpenSSL downlevel version is 1.0.0, and does not support TLS
> 1.2, https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576.
>
> You should be able to connect with -tls1; or build/install OpenSSL
> yourself and use the one installed at /usr/local/ssl/bin/openssl.
>
> > openssl s_client -connect mail.google.com:443
> <http://mail.google.com:443> -tls1_2 -cipher
>
> You can also use -CAfile option for s_client to avoid the verify
> error. Use Google's Google Internet Authority G2 at
> http://pki.google.com/.
>
> Jeff
>
> On Wed, Mar 26, 2014 at 4:14 PM, Thomas Montroy
> <tom.m...@gmail.com <mailto:tom.m...@gmail.com>> wrote:
> > hi All,
> >
> > I've been trying to make ECDHE-ECDSA connections with openssl and
> have been
> > having trouble.
> >
> >
> You can also use -CAfile option for s_client to avoid the verify
> error. Use Google's Google Internet Authority G2 at
> http://pki.google.com/.
>
> Jeff
>
> On Wed, Mar 26, 2014 at 4:14 PM, Thomas Montroy
> <tom.m...@gmail.com <mailto:tom.m...@gmail.com>> wrote:
> > hi All,
> >
> > I've been trying to make ECDHE-ECDSA connections with openssl and
> have been
> > having trouble.
> >
> >
> > openssl s_client -connect mail.google.com:443
> <http://mail.google.com:443> -tls1_2
> > This connects with cipher = ECDHE-RSA-AES128-GCM-SHA256
> >
> > According to Google-Chrome, the cipher for my web-based gmail
> connection
> > should be:
> > ECDHE-ECDSA-AES128-GCM-SHA256
> >
> > If I try to make that connection
> >
> >
> > According to Google-Chrome, the cipher for my web-based gmail
> connection
> > should be:
> > ECDHE-ECDSA-AES128-GCM-SHA256
> >
> > If I try to make that connection
> >
> > openssl s_client -connect mail.google.com:443
> <http://mail.google.com:443> -tls1_2 -cipher
> > ECDHE-ECDSA-AES128-GCM-SHA256
> >
> > I get:
> >
> > CONNECTED(00000003)
> > 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3
> alert
> > handshake failure:s3_pkt.c:1440:SSL alert number 40
> > 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
> handshake
> > failure:s3_pkt.c:617:
> >
> > which looks like no connection.
> >
> > I'm running ubuntu (12.04, I think) on a VM on a Macbook Air
> using VMware. I
> > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no
> luck in any
> > case.
> >
> > I downloaded and compiled the latest version of gnutls:
> >
> > This gives an ECDHE-ECDSA connection
> > gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com
> <http://mail.google.com>
> >
> > I get:
> >
> > CONNECTED(00000003)
> > 139818747868832:error:14094410:SSL routines:ssl3_read_bytes:sslv3
> alert
> > handshake failure:s3_pkt.c:1440:SSL alert number 40
> > 139818747868832:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl
> handshake
> > failure:s3_pkt.c:617:
> >
> > which looks like no connection.
> >
> > I'm running ubuntu (12.04, I think) on a VM on a Macbook Air
> using VMware. I
> > tried the default ubuntu SSL, 1.0.1f, 1.0.1c and 1.0.2beta1, no
> luck in any
> > case.
> >
> > I downloaded and compiled the latest version of gnutls:
> >
> > This gives an ECDHE-ECDSA connection
> > gnutls-cli --priority=NORMAL:-KX-ALL:+ECDHE-ECDSA mail.google.com
> <http://mail.google.com>
> <http://mail.google.com> with
> > gnutls.
> >
> > Any ideas why I can't do that with openssl?
> >
> > Any ideas why I can't do that with openssl?
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> <mailto:openss...@openssl.org>
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openss...@openssl.org
> Automated List Manager majo...@openssl.org
> <mailto:majo...@openssl.org>
>
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
sender by replying to the e-mail containing this attachment. Replies to
this email may be monitored by COMODO for operational or business
reasons. Whilst every endeavour is taken to ensure that e-mails are free
from viruses, no liability can be accepted and the recipient is
requested to use their own virus checking software.
Rob Stradling
Mar 27, 2014, 5:49:01 PM3/27/14
to
On 27/03/14 13:17, Rob Stradling wrote:
> Hi Thomas.
>
> I was told a while ago that Google's servers will only negotiate
> ECDHE-ECDSA if the client i) sends the SNI extension and ii) does _not_
> offer any compression methods.
>
> IINM, s_client always offers zlib compression if zlib support is
> compiled in. It'd be nice if there was a command line switch for
> s_client to disable compression (by setting the SSL_OP_NO_COMPRESSION
> option in the SSL context), but, currently, there isn't.
So Steve pointed out that there is in fact a "-no_comp" switch for
> Hi Thomas.
>
> I was told a while ago that Google's servers will only negotiate
> ECDHE-ECDSA if the client i) sends the SNI extension and ii) does _not_
> offer any compression methods.
>
> IINM, s_client always offers zlib compression if zlib support is
> compiled in. It'd be nice if there was a command line switch for
> s_client to disable compression (by setting the SSL_OP_NO_COMPRESSION
> option in the SSL context), but, currently, there isn't.
s_client that will set SSL_OP_NO_COMPRESSION. That's great. It would
be even greater if it was documented. ;-)
0 new messages