You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2015/11/18 01:10:09 UTC
Fwd: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
s_client -starttls http
I'm fairly certain this will be applied to 1.1.0 and not necessarily
backported to 1.0.2, so this hack might be useful to some of you
who want to test for the preservation of the SSLEngine optional
Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch...
---------- Forwarded message ----------
From: William A. Rowe Jr. via RT <rt...@openssl.org>
Date: Tue, Nov 17, 2015 at 5:26 PM
Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
s_client -starttls http
To:
Cc: openssl-dev@openssl.org
RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL).
Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've
gone ahead and instrumented s_client to support this behavior (and noted a
small optimization in the same logic stream for starttls support).
Attached is the patch to introduce this behavior. It is a bit crufty, but
lacking a CUPS client that did connection upgrade to TLS, I needed
something for testing and experimentation.
I don't know that there is a justification for implementing Upgrade: h2
since this is a binary protocol that is not conducive to terminal mode :)
Source licensed by me under the OpenSSL license at
https://www.openssl.org/source/license.txt - don't see a need for a CLA,
but email me privately if so.
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
s_client -starttls http
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Nov 18, 2015 at 5:19 AM, Bert Huijben <be...@qqmail.nl> wrote:
> Hi William,
>
>
>
> Is any commonly used client actually implementing this spec in a way that
> makes this RFC relevant for httpd?
>
>
Note httpd already implements this correctly, it's simply a matter of not
breaking it. My quick checks indicate that 2.4.18-dev is working well.
Next check is the protocols patch in the queue.
My checks with -starttls ftp indicate we broke mod_ftp auth over explicit
tls connections some time back in 2.4.13-dev when we had fixed error
document response to speaking plain http over https. Need to see how many
other ways mod_ftp tls has been corrupted recently, but will probably
leverage mod_ssl's internal upgrade handling for the mod_ftp use case.
The major peering for this upgrade logic has been CUPS printing. Outside
of this case there has been fairly little traction.
SNI and ALPN both solve issues that this spec was designed to solve (host,
then tls handshake, upgrade to a specific protocol etc).
What it now solves is limited to consolidating on port 80, and very few
clients ever picked this up.
> Sure we could implement this… Perhaps we already did but once you switch
> to TLS there are so many security related things to account for.
>
>
>
> Ignoring the server certificate case, what about SNI and ALPN?
>
>
>
> Is there really a specific upgrade to tls/1.0, 1.1 and 1.2. Or is one
> upgrade enough as the handshake does the rest.
>
The spec suggests it is called out, but you are correct, in this tool we
begin at the appropriate -tls1_2 provided (fixing Yann's observation) but
perform a normal handshake.
Does this also allow switching to http/2 in one step via ALPN?
>
>
>
> Or is that explicitly forbidden?
>
There is an interesting thread
http://www.ietf.org/mail-archive/web/httpbisa/current/msg24147.html and
further discussion about ALPN vs Upgrade and the coexistence of the two
schemas.
RE: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http
Posted by Bert Huijben <be...@qqmail.nl>.
Hi William,
Is any commonly used client actually implementing this spec in a way that makes this RFC relevant for httpd?
Sure we could implement this… Perhaps we already did but once you switch to TLS there are so many security related things to account for.
Ignoring the server certificate case, what about SNI and ALPN?
Is there really a specific upgrade to tls/1.0, 1.1 and 1.2. Or is one upgrade enough as the handshake does the rest.
Does this also allow switching to http/2 in one step via ALPN?
Or is that explicitly forbidden?
Bert
From: William A Rowe Jr [mailto:wrowe@rowe-clan.net]
Sent: woensdag 18 november 2015 01:10
To: httpd <de...@httpd.apache.org>
Subject: Fwd: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http
I'm fairly certain this will be applied to 1.1.0 and not necessarily
backported to 1.0.2, so this hack might be useful to some of you
who want to test for the preservation of the SSLEngine optional
Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch...
---------- Forwarded message ----------
From: William A. Rowe Jr. via RT <rt@openssl.org <ma...@openssl.org> >
Date: Tue, Nov 17, 2015 at 5:26 PM
Subject: [openssl-dev] [openssl.org <http://openssl.org> #4145] Enhancement: patch to support s_client -starttls http
To:
Cc: openssl-dev@openssl.org <ma...@openssl.org>
RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL).
Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've
gone ahead and instrumented s_client to support this behavior (and noted a
small optimization in the same logic stream for starttls support).
Attached is the patch to introduce this behavior. It is a bit crufty, but
lacking a CUPS client that did connection upgrade to TLS, I needed
something for testing and experimentation.
I don't know that there is a justification for implementing Upgrade: h2
since this is a binary protocol that is not conducive to terminal mode :)
Source licensed by me under the OpenSSL license at
https://www.openssl.org/source/license.txt - don't see a need for a CLA,
but email me privately if so.
_______________________________________________
openssl-bugs-mod mailing list
openssl-bugs-mod@openssl.org <ma...@openssl.org>
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
s_client -starttls http
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Bill,
thanks, this will be quite useful.
A little note, probably some missing == here:
+ else if (meth = TLSv1_2_client_method())
+ BIO_printf(fbio, "Upgrade: TLS/1.2\r\n");
+ else if (meth = TLSv1_1_client_method())
+ BIO_printf(fbio, "Upgrade: TLS/1.1\r\n");
+ else if (meth = TLSv1_client_method())
+ BIO_printf(fbio, "Upgrade: TLS/1.0\r\n");
+
Cheers,
Yann.
On Wed, Nov 18, 2015 at 1:10 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> I'm fairly certain this will be applied to 1.1.0 and not necessarily
> backported to 1.0.2, so this hack might be useful to some of you
> who want to test for the preservation of the SSLEngine optional
> Upgrade: TLS/1.0 behavior on trunk and 2.4.x branch...
>
>
>
> ---------- Forwarded message ----------
> From: William A. Rowe Jr. via RT <rt...@openssl.org>
> Date: Tue, Nov 17, 2015 at 5:26 PM
> Subject: [openssl-dev] [openssl.org #4145] Enhancement: patch to support
> s_client -starttls http
> To:
> Cc: openssl-dev@openssl.org
>
>
> RFC 2817 defines upgrading HTTP/1.1 to TLS (or SSL).
>
> Because Apache httpd supports Connection: Upgrade and Upgrade: TLS/1.x I've
> gone ahead and instrumented s_client to support this behavior (and noted a
> small optimization in the same logic stream for starttls support).
>
> Attached is the patch to introduce this behavior. It is a bit crufty, but
> lacking a CUPS client that did connection upgrade to TLS, I needed
> something for testing and experimentation.
>
> I don't know that there is a justification for implementing Upgrade: h2
> since this is a binary protocol that is not conducive to terminal mode :)
>
> Source licensed by me under the OpenSSL license at
> https://www.openssl.org/source/license.txt - don't see a need for a CLA,
> but email me privately if so.
>
>
> _______________________________________________
> openssl-bugs-mod mailing list
> openssl-bugs-mod@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>