Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
What is "Secure Renegotiation" and why is it used, and how to have the client adapt to it?
1,925 views
Skip to first unread message
Ted Byers
Nov 29, 2012, 2:24:41 PM11/29/12
to
Please consider the following output:
The same command, getting Google's home page over SSL produces the following:
But it now occurs to me that "Secure Renegotiation" might not be the problem. After all, the output related to it when accessing Google comes after the server certificate is received, and no certificate is received from this problem server. And it isn't feasible for me to muck around with the server because I do not have that kind of access (it is owned/managed by another company). Therefore, I have another question, which is, how to I determine and verify the real cause of the problem, and then, how do I fix it?
Thanks
Ted
C:\Work>openssl s_client -connect secure.theserver.com:443
Loading 'screen' into random state - done
CONNECTED(000000F0)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 321 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Loading 'screen' into random state - done
CONNECTED(000000F0)
write:errno=10054
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 321 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
The same command, getting Google's home page over SSL produces the following:
C:\Work>openssl s_client -connect www.google.com:443
Loading 'screen' into random state - done
CONNECTED(000000F0)
depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x
MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy
wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B
d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp
ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le
IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 2130 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 5930A80165EBF4CDA0199A366CB1232C54B4F70B3CEE0690561A9514AB8A27EB
Session-ID-ctx:
Master-Key: A107E655BBC4DC3E28B81CA9986414F2D56E942590F794822EC435D3F907C45C7E93D866DF3D082DBE3573278899648D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - c5 c4 5c ba a7 ff ca 4c-59 f9 5e 08 80 e6 76 3c ..\....LY.^...v<
0010 - e8 13 92 e8 96 2d 91 fd-e2 ad ff 33 fe ab 16 6d .....-.....3...m
0020 - 18 15 77 3d f1 d4 b8 24-fe 19 ac 46 b9 69 52 1a ..w=...$...F.iR.
0030 - ac db e2 2c 92 33 6c a8-8e 69 f6 3a 65 6d 29 91 ...,.3l..i.:em).
0040 - a3 d3 08 6e a7 da 64 f0-88 c7 d4 e3 b4 29 ba 20 ...n..d......).
0050 - a6 31 52 e5 c0 0b 42 b5-da 9c 6d 43 59 17 1e dd .1R...B...mCY...
0060 - 8a 09 0c ee 03 9b 6a a7-87 23 ef d6 2d 61 23 d0 ......j..#..-a#.
0070 - 0c 16 c4 69 8c 42 d4 35-00 ae a1 c7 e6 c9 75 2d ...i.B.5......u-
0080 - e2 f7 be 82 93 c2 2c ba-35 67 89 98 c5 8f 47 cb ......,.5g....G.
0090 - b4 75 9f c2 .u..
Start Time: 1354196309
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=0
I need to know, first, what "Secure Renegotiation" is, and then, if it is a legitimate way to configure a secure server, why it is used. Finally, I need to know what needs to be done to have a client application adapt to it. Firefox seems to have no problem with it, but my Perl programs that actually use the server in question do appear to have a problem with it.Loading 'screen' into random state - done
CONNECTED(000000F0)
depth=1 C = ZA, O = Thawte Consulting (Pty) Ltd., CN = Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x
MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy
wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B
d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM
BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp
ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le
IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q==
-----END CERTIFICATE-----
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
---
No client certificate CA names sent
---
SSL handshake has read 2130 bytes and written 443 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-RC4-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-RC4-SHA
Session-ID: 5930A80165EBF4CDA0199A366CB1232C54B4F70B3CEE0690561A9514AB8A27EB
Session-ID-ctx:
Master-Key: A107E655BBC4DC3E28B81CA9986414F2D56E942590F794822EC435D3F907C45C7E93D866DF3D082DBE3573278899648D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - c5 c4 5c ba a7 ff ca 4c-59 f9 5e 08 80 e6 76 3c ..\....LY.^...v<
0010 - e8 13 92 e8 96 2d 91 fd-e2 ad ff 33 fe ab 16 6d .....-.....3...m
0020 - 18 15 77 3d f1 d4 b8 24-fe 19 ac 46 b9 69 52 1a ..w=...$...F.iR.
0030 - ac db e2 2c 92 33 6c a8-8e 69 f6 3a 65 6d 29 91 ...,.3l..i.:em).
0040 - a3 d3 08 6e a7 da 64 f0-88 c7 d4 e3 b4 29 ba 20 ...n..d......).
0050 - a6 31 52 e5 c0 0b 42 b5-da 9c 6d 43 59 17 1e dd .1R...B...mCY...
0060 - 8a 09 0c ee 03 9b 6a a7-87 23 ef d6 2d 61 23 d0 ......j..#..-a#.
0070 - 0c 16 c4 69 8c 42 d4 35-00 ae a1 c7 e6 c9 75 2d ...i.B.5......u-
0080 - e2 f7 be 82 93 c2 2c ba-35 67 89 98 c5 8f 47 cb ......,.5g....G.
0090 - b4 75 9f c2 .u..
Start Time: 1354196309
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
read:errno=0
But it now occurs to me that "Secure Renegotiation" might not be the problem. After all, the output related to it when accessing Google comes after the server certificate is received, and no certificate is received from this problem server. And it isn't feasible for me to muck around with the server because I do not have that kind of access (it is owned/managed by another company). Therefore, I have another question, which is, how to I determine and verify the real cause of the problem, and then, how do I fix it?
Thanks
Ted
Jeffrey Walton
Nov 29, 2012, 2:57:10 PM11/29/12
to
> I need to know, first, what "Secure Renegotiation" is, and then, if it is a
> legitimate way to configure a secure server, why it is used.
Secure Renegotiation is a variant of the original negotiation supplied
> legitimate way to configure a secure server, why it is used.
in SSL way back when. There were two separate issues in renegotiation.
First was an authentication gap, and second was a DoS by the folks at
THC (the latter is disputed by libraries such as OpenSSL and NSS).
The authentication gap can be found all over the web by searching for
"TLS Authentication Gap." Also see CVE-2009-3555 and
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
The group THC released a DoS tool. See CVE-2011-1473, CVE-2011-5094,
and http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html.
You can find the details of the steps taken in Secure Renegotiation at
https://tools.ietf.org/rfc/rfc5246.txt.
I don't allow renegotiation in code under my purview. I don't want a
connection starting out secure, and then change to insecure via choice
of weak/wounded ciphers. It also adds extra, useless code that has
been exploited in the past. But that's just my opinion.
> need to know what needs to be done to have a client application adapt to it.
> Firefox seems to have no problem with it, but my Perl programs that actually
> use the server in question do appear to have a problem with it.
to date? If so, have the PERL maintainers kept its gear up to date
with the latest standard?
> And it isn't feasible for me to muck around with
> the server because I do not have that kind of access (it is owned/managed by
> another company).
up to date, too.
Jeff
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
Dave Thompson
Nov 29, 2012, 5:00:01 PM11/29/12
to
> From: owner-ope...@openssl.org On Behalf Of Jeffrey Walton
> Sent: Thursday, 29 November, 2012 14:57
> > I need to know, first, what "Secure Renegotiation" is, and
> then, if it is a
> > legitimate way to configure a secure server, why it is used.
> Secure Renegotiation is a variant of the original negotiation supplied
> in SSL way back when. There were two separate issues in renegotiation.
> First was an authentication gap, and second was a DoS by the folks at
> THC (the latter is disputed by libraries such as OpenSSL and NSS).
>
> The authentication gap can be found all over the web by searching for
> "TLS Authentication Gap." Also see CVE-2009-3555 and
> http://www.educatedguesswork.org/2009/11/understanding_the_tls
> _renegoti.html
>
> The group THC released a DoS tool. See CVE-2011-1473, CVE-2011-5094,
> and http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html.
>
> You can find the details of the steps taken in Secure Renegotiation at
> https://tools.ietf.org/rfc/rfc5246.txt.
>
*5746* is Secure Renegotiation (or officially Renegotiation
Indication), which is an extension that can modify any TLS
version: 1.0 is 2246, 1.1 is 4346, and 1.2 is *5246*.
The "DoS" -- or at least server load -- caused by renegotiation is
not altered in any way by 5746; it is inherent in the re/negotiation
(handshake) protocol if using RSA which 99.99% of the Internet does.
(For DSA and ECDSA the load is more even, and for PSK or KRB, or null,
there is essentially no load. But practically nobody uses those.) And
it differs from the "DoS" of just doing lots of initial negotiations
ONLY in that it occurs on existing TCP connections and not new ones,
which makes it a little harder for external fixes like firewall rate
limits (but not impossible, because the handshake-type records *are*
detectable in the TCP data).
> I don't allow renegotiation in code under my purview. I don't want a
> connection starting out secure, and then change to insecure via choice
> of weak/wounded ciphers. It also adds extra, useless code that has
> been exploited in the past. But that's just my opinion.
>
> > need to know what needs to be done to have a client
> application adapt to it.
> > Firefox seems to have no problem with it, but my Perl
> programs that actually
> > use the server in question do appear to have a problem with it.
> To support it, a client needs to be compliant. Is your PERL client up
> to date? If so, have the PERL maintainers kept its gear up to date
> with the latest standard?
>
Perl is almost certainly not implementing SSL/TLS itself but
calling a library like OpenSSL or GNUTLS, which might be installed
as part of some Perl package or separately, so the real questions
are: is the Perl module(s?) compatible with an uptodate library,
is the uptodate library included in the Perl install or otherwise
installed, and if any options or config need to be set are they?
However, if openssl s_client can't even start to handshake (below)
probably perl can't either and this has nothing to do with 5746.
> > following: <snip>
> > But it now occurs to me that "Secure Renegotiation" might not be the
> > problem. After all, the output related to it when
> accessing Google comes
> > after the server certificate is received, and no
> certificate is received
> > from this problem server. And it isn't feasible for me to
> muck around with
> > the server because I do not have that kind of access (it is
> owned/managed by
> > another company). Therefore, I have another question,
> which is, how to I
> > determine and verify the real cause of the problem, and
> then, how do I fix
Not only did you not receive server cert from the problem server,
you didn't even *send* ClientHello (note error on *write*).
That definitely has nothing whatsoever to do with 5746.
Since you are on Windows (or a very good imitation) 10054 is
really RST received -- and here even before your first send.
Although RST was originally meant to be from the peer, and
the official Windows error string still (at least in 7) says
"forcibly closed by the remote host", in fact nowadays lots of
middleboxes like firewalls use RST to break connections.
I'd guess your best bet is that some firewall (possibly
including software on the server host) is deciding to break
your connection, for some reason that some admin or manager
or developer somewhere thought up. I'd suggest first verifying
this by getting a network-level trace: on Windows I recommend
www.wireshark.org as easy to install and use; check that
you are actually getting RST, and: does seq# match (host
should always but in my experience firewalls sometimes not)?
any other flags? from what (claimed) IP and MAC?
If your net connection goes through your own firewall,
NAT router, or similar, try a trace outboard of that.
See if you can traceroute (tracert on Windows) to their
host, although the sorts of net people who wrongly deny
TCP connections tend to unnecessarily ban ICMP echo also.
If you can establish the RST is coming from the target
company, and you can't get someone there to help find
the problem, you're probably out of luck.
> Sent: Thursday, 29 November, 2012 14:57
> > I need to know, first, what "Secure Renegotiation" is, and
> then, if it is a
> > legitimate way to configure a secure server, why it is used.
> Secure Renegotiation is a variant of the original negotiation supplied
> in SSL way back when. There were two separate issues in renegotiation.
> First was an authentication gap, and second was a DoS by the folks at
> THC (the latter is disputed by libraries such as OpenSSL and NSS).
>
> The authentication gap can be found all over the web by searching for
> "TLS Authentication Gap." Also see CVE-2009-3555 and
> http://www.educatedguesswork.org/2009/11/understanding_the_tls
> _renegoti.html
>
> The group THC released a DoS tool. See CVE-2011-1473, CVE-2011-5094,
> and http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html.
>
> You can find the details of the steps taken in Secure Renegotiation at
> https://tools.ietf.org/rfc/rfc5246.txt.
>
Indication), which is an extension that can modify any TLS
version: 1.0 is 2246, 1.1 is 4346, and 1.2 is *5246*.
The "DoS" -- or at least server load -- caused by renegotiation is
not altered in any way by 5746; it is inherent in the re/negotiation
(handshake) protocol if using RSA which 99.99% of the Internet does.
(For DSA and ECDSA the load is more even, and for PSK or KRB, or null,
there is essentially no load. But practically nobody uses those.) And
it differs from the "DoS" of just doing lots of initial negotiations
ONLY in that it occurs on existing TCP connections and not new ones,
which makes it a little harder for external fixes like firewall rate
limits (but not impossible, because the handshake-type records *are*
detectable in the TCP data).
> I don't allow renegotiation in code under my purview. I don't want a
> connection starting out secure, and then change to insecure via choice
> of weak/wounded ciphers. It also adds extra, useless code that has
> been exploited in the past. But that's just my opinion.
>
> > need to know what needs to be done to have a client
> application adapt to it.
> > Firefox seems to have no problem with it, but my Perl
> programs that actually
> > use the server in question do appear to have a problem with it.
> To support it, a client needs to be compliant. Is your PERL client up
> to date? If so, have the PERL maintainers kept its gear up to date
> with the latest standard?
>
calling a library like OpenSSL or GNUTLS, which might be installed
as part of some Perl package or separately, so the real questions
are: is the Perl module(s?) compatible with an uptodate library,
is the uptodate library included in the Perl install or otherwise
installed, and if any options or config need to be set are they?
However, if openssl s_client can't even start to handshake (below)
probably perl can't either and this has nothing to do with 5746.
> > But it now occurs to me that "Secure Renegotiation" might not be the
> > problem. After all, the output related to it when
> accessing Google comes
> > after the server certificate is received, and no
> certificate is received
> > from this problem server. And it isn't feasible for me to
> muck around with
> > the server because I do not have that kind of access (it is
> owned/managed by
> > another company). Therefore, I have another question,
> which is, how to I
> > determine and verify the real cause of the problem, and
> then, how do I fix
you didn't even *send* ClientHello (note error on *write*).
That definitely has nothing whatsoever to do with 5746.
Since you are on Windows (or a very good imitation) 10054 is
really RST received -- and here even before your first send.
Although RST was originally meant to be from the peer, and
the official Windows error string still (at least in 7) says
"forcibly closed by the remote host", in fact nowadays lots of
middleboxes like firewalls use RST to break connections.
I'd guess your best bet is that some firewall (possibly
including software on the server host) is deciding to break
your connection, for some reason that some admin or manager
or developer somewhere thought up. I'd suggest first verifying
this by getting a network-level trace: on Windows I recommend
www.wireshark.org as easy to install and use; check that
you are actually getting RST, and: does seq# match (host
should always but in my experience firewalls sometimes not)?
any other flags? from what (claimed) IP and MAC?
If your net connection goes through your own firewall,
NAT router, or similar, try a trace outboard of that.
See if you can traceroute (tracert on Windows) to their
host, although the sorts of net people who wrongly deny
TCP connections tend to unnecessarily ban ICMP echo also.
If you can establish the RST is coming from the target
company, and you can't get someone there to help find
the problem, you're probably out of luck.
0 new messages