> From: owner-openssl-us...@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. > > 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). > They probably told you they have a patch policy and keep their servers > up to date, too. > > Jeff > > On Thu, Nov 29, 2012 at 2:24 PM, Ted Byers > <r.ted.by...@gmail.com> wrote: > > Please consider the following output: > > > > 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 > > --- > > > > The same command, getting Google's home page over SSL produces the > > 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. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
