[stunnel-users] Extensions when negotiating TLS

[Tom (AST) Watson]

Chris...

I think I have solutions in hand.  I have app#2 talking unencrypted where I want it.  This makes it easier to monitor the transactions over the wire which is one of the reasons for setting things up.  Yes, it would be nice to be encrypted everywhere, but this is a closed (very experimental) system, and being unencrypted is helpful.  Both sides want http2, and that is life, but I believe things are going my way.  I'm muddling through the GO code, and while I try not to poke the beehive to much (might break it!) solutions are there.  It looks like I can use stunnel for part of the problem, and go from there.

Of course, it might be useful to others if stunnel accepted ALPN requests, but it looks like I can save that for another time.

Thanks for the help.

...Tom

-----Original Message-----
From: stunnel-users <stunnel-users-bounces at stunnel.org> On Behalf Of 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
>>
>