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(a)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(a)stunnel.org> On Behalf Of Christopher Schultz
>> Sent: Monday, November 4, 2019 13:59 To: stunnel-users(a)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
>>
>
