[stunnel-users] Extensions when negotiating TLS

[Christopher Schultz]

Tom,

On 11/4/19 17:59, Tom (AST) Watson wrote:
> Trying to make the applications want to talk http/1.1 isn't going to
> be easy.  Both sides (app#1 and app#2) want to talk http2 (*SIGH*).
Understood.

> I was just hoping stunnel might work.  Presently it looks like it 
> won't so I am looking at alternatives.  Part of the object is to look
> at the various transactions over the wire (many!) and they are lots.
> I assume that is why http2 is used, and I have no influence over
> that decision.  From the looks of it, making app#2 unencrypted is the
> best path.

Boo!

> It is written in GO, and has little comments to describe things (such
> is life!).  I think I'm a bit closer to a solution, but if stunnel
> can be made to work (ALPN support) it would be nice. Looks like I'll
> have to wait.
Why isn't it an option to enable encryption directly on the service? It
seems like using stunnel should be your last resort.

-chris

> -----Original Message-----
> From: stunnel-users <stunnel-users-bounces at stunnel.org> On Behalf Of Christopher Schultz
> 
> Tom,
> 
> On 11/4/19 17:16, Tom (AST) Watson wrote:
>> Yes, I understand about ALPN.  Sorry I described in detail. 
>> Unfortunately application #2 wants encrypted http2 (it is a go 
>> program). Application #1 wants to talk in http2 (I can't change
>> that!) and it doesn't encrypt "naturally" (and I want to see what is 
>> going on [Wireshark] as well) In looking further I might be able to 
>> get application #2 to go plaintext (I found a pointer). Yes, it seems 
>> that stunnel doesn't support ALPN, wishful thinking on my part
>>
>> Back to the salt mines. (*SIGH*)
> 
> How difficult would it be to enable HTTP/1.1 on that application #1?
> I've never seen an h2-only service before. h2 is more effective for web applications that make a lot of tiny requests (like small resources for pages, scripts, etc.). Most API-based services don't really get any benefit from using h2.
> 
> -chris
> 
>> -----Original Message----- From: stunnel-users 
>> <stunnel-users-bounces at stunnel.org> On Behalf Of Christopher Schultz
>> Sent: Monday, November 4, 2019 13:59 To: stunnel-users at stunnel.org
>> Subject: [External] Re: [stunnel-users] Extensions when negotiating 
>> TLS
>>
>> Tom,
>>
>> On 11/4/19 16:05, Tom (AST) Watson wrote:
>>> Well, I thought it would be "easy", but maybe not.  I have an 
>>> application (#1) that uses http2, and isn't encrypted.  No problem  
>>> here.  Now I have another application (#2) that insists on using 
>>> https to talk to application #1.  So I gleefully setup stunnel to 
>>> connect the two.  Well, application #2 starts talking to stunnel with 
>>> a "Client Hello" packet, and it includes an extension "Application 
>>> Layer Protocol Extension" of "h2".
>>
>> This is called ALPN, and is a requirement for h2s.
>>
>>> While not versed in the minutia, I take this that the client 
>>> (application #2) wants to talk "http2" to the server (application 
>>> #1).
>>
>> Yep, pretty much.
>>
>>> OK, that is what I want.  The problem is that stunnel doesn't respond 
>>> with ANY "Application Layer Protocol Extension" indicating acceptance 
>>> of this request in its "server hello".  This means that application 
>>> #2 fails in its negotiation.  No joy!
>>>
>>> Now I know that application #1 will nicely talk http2, but how do I  
>>> get stunnel to communicate this to application #2 (as encrypted 
>>> http2).  Am I missing something in my (pretty simple) configuration  
>>> file?
>>
>> I can't find any references to stunnel supporting ALPN. You may be
>> (temporarily) out of luck, at least with stunnel.
>>
>> You mentioned that app #2 insists on encryption (great, usually). Is 
>> there a requirement that it use h2? Or can it be configured to use 
>> HTTP/1.1?
>>
>> -chris
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20191105/e40ebca9/attachment.sig>