Quantcast

[Patch] ALPN Implementation for OpenSSL

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Patch] ALPN Implementation for OpenSSL

Parashuram Narasimhan (MS OPEN TECH)
Hi,

I work for Microsoft Open Technologies, a wholly owned subsidiary of Microsoft Corp. My team is currently working on the standardization process for HTTP/2.0: as I believe many of you may have heard, the latest working draft @ IETF requires using ALPN as the mechanism for secure negotiation, and we have been working on a patch to OpenSSL to allow for early testing and interoperability. More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3, but for your convenience here goes the relevant snippet:

2.3.  Starting HTTP/2.0 for "https:" URIs
 
   A client that makes a request to an "https:" URI without prior
   knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the
   application layer protocol negotiation extension [TLSALPN].
 
   Once TLS negotiation is complete, both the client and the server send
   a connection header (Section 3.2).


We will be submitting a patch request to [hidden email] as advised by https://github.com/openssl/openssl/blob/master/README#L178, and we will be following discussions the mailing lists. Please feel free to give us your feedback and, in case you would be interested in a formal contribution, advice on the steps we need to take.

Thanks

Parashuram
Microsoft Open Technologies Inc
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Parashuram Narasimhan (MS OPEN TECH)
Hi,

Attached the Patch for the OpenSSL with ALPN implementation.

-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH)
Sent: Thursday, June 13, 2013 5:57 AM
To: '[hidden email]'
Subject: [Patch] ALPN Implementation for OpenSSL

Hi,

I work for Microsoft Open Technologies, a wholly owned subsidiary of Microsoft Corp. My team is currently working on the standardization process for HTTP/2.0: as I believe many of you may have heard, the latest working draft @ IETF requires using ALPN as the mechanism for secure negotiation, and we have been working on a patch to OpenSSL to allow for early testing and interoperability. More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3, but for your convenience here goes the relevant snippet:

2.3.  Starting HTTP/2.0 for "https:" URIs
 
   A client that makes a request to an "https:" URI without prior
   knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the
   application layer protocol negotiation extension [TLSALPN].
 
   Once TLS negotiation is complete, both the client and the server send
   a connection header (Section 3.2).


We will be submitting a patch request to [hidden email] as advised by https://github.com/openssl/openssl/blob/master/README#L178, and we will be following discussions the mailing lists. Please feel free to give us your feedback and, in case you would be interested in a formal contribution, advice on the steps we need to take.

Thanks

Parashuram
Microsoft Open Technologies Inc

openssl-alpn.patch (39K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Parashuram Narasimhan (MS OPEN TECH)
In reply to this post by Parashuram Narasimhan (MS OPEN TECH)
Hi,

I realize it has only been a few days since we originally posted this patch for Application Layer Protocol Negotiation (ALPN) support. I just wanted to expand on why we think this is an important patch for OpenSSL.
The latest HTTP/2.0 draft specifies support for a TLS extension called ALPN to negotiate HTTP/2.0 within the TLS handshake: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-01

As I wrote in the original message [ http://www.mail-archive.com/openssl-dev@.../msg32630.html ] -

More background is available at http://tools.ietf.org/html/draft-ietf-httpbis-http2-03#section-2.3, but for your convenience here goes the relevant snippet:

2.3.  Starting HTTP/2.0 for "https:" URIs
 
   A client that makes a request to an "https:" URI without prior
   knowledge about support for HTTP/2.0 uses TLS [RFC5246] with the
   application layer protocol negotiation extension [TLSALPN].
 
   Once TLS negotiation is complete, both the client and the server send
   a connection header (Section 3.2).


The good news is we've already implemented it. We really want to work with you to get this patch into OpenSSL to help developers of HTTP/2.0 draft implementations. We welcome your assistance to review this patch.


--
Parashuram
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Piotr Sikora
Hi,

> We really want to work with you to get this patch into OpenSSL to help developers of HTTP/2.0 draft implementations. We welcome your assistance to review this patch.

What really makes this patch unusable (at least for us) is this snippet:

+#if !defined(OPENSSL_NO_NEXTPROTONEG) && !defined(OPENSSL_NO_ALPN)
+#error "Cannot define both NPN and ALPN"
+#endif

We simply cannot drop support for NPN (i.e. SPDY) just to add support for ALPN.

IMHO, the correct solution would be to always prefer and offer ALPN,
unless client announced only NPN support in Client Hello.

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Jeff Mendoza (MS OPEN TECH)
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Piotr Sikora
> Sent: Thursday, June 20, 2013 10:41 AM
> To: [hidden email]
> Subject: Re: [Patch] ALPN Implementation for OpenSSL
>
> We simply cannot drop support for NPN (i.e. SPDY) just to add support for
> ALPN.

The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.

Thanks,
Jeff Mendoza


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Ben Laurie-2
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH)
<[hidden email]> wrote:

>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> On Behalf Of Piotr Sikora
>> Sent: Thursday, June 20, 2013 10:41 AM
>> To: [hidden email]
>> Subject: Re: [Patch] ALPN Implementation for OpenSSL
>>
>> We simply cannot drop support for NPN (i.e. SPDY) just to add support for
>> ALPN.
>
> The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.

That doesn't make any sense. How would a server serve both NPN and ALPN?
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Piotr Sikora
In reply to this post by Jeff Mendoza (MS OPEN TECH)
Hey Jeff,

> The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.

Yeah, my point was that in the perfect world, you'd support both at
runtime (at least on the server-side) and either ALPN or NPN could be
used. I want to have a library that supports both, not either-or.

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Jeff Mendoza (MS OPEN TECH)
> Yeah, my point was that in the perfect world, you'd support both at
> runtime (at least on the server-side) and either ALPN or NPN could be
> used. I want to have a library that supports both, not either-or.

Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct?

Thanks,
Jeff Mendoza

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Piotr Sikora
Hey,

> Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct?

It would also make it kind of useless, at least from my
non-authoritative point of view.

Best regards,
Piotr Sikora
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Thor Lancelot Simon-2
In reply to this post by Jeff Mendoza (MS OPEN TECH)
On Thu, Jun 20, 2013 at 09:30:32PM +0000, Jeff Mendoza (MS OPEN TECH) wrote:
> > Yeah, my point was that in the perfect world, you'd support both at
> > runtime (at least on the server-side) and either ALPN or NPN could be
> > used. I want to have a library that supports both, not either-or.
>
> Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct?

I don't speak for the OpenSSL project, but I'd suggest they should treat
it as one.  It positively reeks of "embrace and extend".  After all, the
effect is to force all build systems producing system default packages
of OpenSSL to pick one way or the other, ensuring that both won't work
at the same time.

Thor
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Rajesh Malepati
In reply to this post by Ben Laurie-2
On Fri, Jun 21, 2013 at 2:21 AM, Ben Laurie <[hidden email]> wrote:
On 20 June 2013 21:46, Jeff Mendoza (MS OPEN TECH)
<[hidden email]> wrote:
>> -----Original Message-----
>> From: [hidden email] [mailto:[hidden email]]
>> On Behalf Of Piotr Sikora
>> Sent: Thursday, June 20, 2013 10:41 AM
>> To: [hidden email]
>> Subject: Re: [Patch] ALPN Implementation for OpenSSL
>>
>> We simply cannot drop support for NPN (i.e. SPDY) just to add support for
>> ALPN.
>
> The idea is to have the choice as a ./config option. The default will stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.

That doesn't make any sense. How would a server serve both NPN and ALPN?

Think of all the distributions that package OpenSSL. What should they choose?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Ben Laurie-2
In reply to this post by Thor Lancelot Simon-2
On 21 June 2013 02:29, Thor Lancelot Simon <[hidden email]> wrote:

> On Thu, Jun 20, 2013 at 09:30:32PM +0000, Jeff Mendoza (MS OPEN TECH) wrote:
>> > Yeah, my point was that in the perfect world, you'd support both at
>> > runtime (at least on the server-side) and either ALPN or NPN could be
>> > used. I want to have a library that supports both, not either-or.
>>
>> Yes, supporting both at runtime would be best. But having a compile-time option now, and defaulting to NPN should keep this from being a blocking issue with the patch, correct?
>
> I don't speak for the OpenSSL project, but I'd suggest they should treat
> it as one.  It positively reeks of "embrace and extend".  After all, the
> effect is to force all build systems producing system default packages
> of OpenSSL to pick one way or the other, ensuring that both won't work
> at the same time.

That's not really "embrace and extend", but nevertheless it seems like
an unacceptable design choice.

I suggest you need to figure out how to make both ALPN and NPN work in
a single build to have any chance of acceptance at all.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Jeff Mendoza (MS OPEN TECH)
In reply to this post by Piotr Sikora
Hi All,

> > Yes, supporting both at runtime would be best. But having a compile-time
> option now, and defaulting to NPN should keep this from being a blocking
> issue with the patch, correct?
>
> It would also make it kind of useless, at least from my non-authoritative
> point of view.

Understood, I'll start working on this behavior:

The client can send ALPN, NPN, or both.
  If the client only sends one: negotiation will take place normally.
  If the client sends both: the server will prefer ALPN. If nothing matches with ALPN, it will fall back to NPN and send its list.

Also, we have received some feedback off-list on the code we have already posted, and will be reposting with some updates soon.

Thanks,
Jeff Mendoza

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Jeff Mendoza (MS OPEN TECH)
In reply to this post by Ben Laurie-2
> >> We simply cannot drop support for NPN (i.e. SPDY) just to add support
> >> for ALPN.
> >
> > The idea is to have the choice as a ./config option. The default will
> stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.
>
> That doesn't make any sense. How would a server serve both NPN and ALPN?

Ben, does the proposed solution (on the other thread) work for you?

Thanks,
Jeff Mendoza


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Patch] ALPN Implementation for OpenSSL

Ben Laurie-2
On 24 June 2013 22:00, Jeff Mendoza (MS OPEN TECH)
<[hidden email]> wrote:
>> >> We simply cannot drop support for NPN (i.e. SPDY) just to add support
>> >> for ALPN.
>> >
>> > The idea is to have the choice as a ./config option. The default will
>> stay as NPN, as to not disrupt anyone. I don't have this in the patch yet.
>>
>> That doesn't make any sense. How would a server serve both NPN and ALPN?
>
> Ben, does the proposed solution (on the other thread) work for you?

Sounds OK to me, yes.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: [Patch] ALPN Implementation for OpenSSL

Jeff Mendoza (MS OPEN TECH)
In reply to this post by Jeff Mendoza (MS OPEN TECH)
> Understood, I'll start working on this behavior:
>
> The client can send ALPN, NPN, or both.
>   If the client only sends one: negotiation will take place normally.
>   If the client sends both: the server will prefer ALPN. If nothing
> matches with ALPN, it will fall back to NPN and send its list.
>
> Also, we have received some feedback off-list on the code we have already
> posted, and will be reposting with some updates soon.

Hi All,

I have posted our updated ALPN patch, http://rt.openssl.org/Ticket/Display.html?id=3073. I'm happy to address any feedback. Also, there have been some questions about testing. The new patch has added support to s_client and s_server which should enable testing ALPN without any dependencies.

Thanks,
Jeff Mendoza


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Loading...