Re: Extensions when negotiating TLS

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============5176482814168814665==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Mb8haPc0176MZcZHZqYtis5ax55qON5rN"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Mb8haPc0176MZcZHZqYtis5ax55qON5rN
Content-Type: multipart/mixed; boundary="lnI4q3cFOCBUgPuBzbos2Ys55iLU39l9D";
 protected-headers="v1"
From: Christopher Schultz <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: [stunnel-users] Extensions when negotiating TLS
References: <c92c5a6e51824325b83c1bc0f2098847@SN1F00803MB0045.008f.mgd2.msft.net>
 <[email protected]>
 <76d9d4dcfaa74e36acccc9f64be68343@SN1F00803MB0045.008f.mgd2.msft.net>
 <[email protected]>
 <e5324b2c11c54424aae7d799d41f1908@SN1F00803MB0045.008f.mgd2.msft.net>
In-Reply-To: <e5324b2c11c54424aae7d799d41f1908@SN1F00803MB0045.008f.mgd2.msft.net>

--lnI4q3cFOCBUgPuBzbos2Ys55iLU39l9D
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

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=20
> 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 <[email protected]> On Behalf Of Ch=
ristopher Schultz
>=20
> Tom,
>=20
> On 11/4/19 17:16, Tom (AST) Watson wrote:
>> Yes, I understand about ALPN.  Sorry I described in detail.=20
>> Unfortunately application #2 wants encrypted http2 (it is a go=20
>> 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=20
>> going on [Wireshark] as well) In looking further I might be able to=20
>> 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*)
>=20
> 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 benef=
it from using h2.
>=20
> -chris
>=20
>> -----Original Message----- From: stunnel-users=20
>> <[email protected]> On Behalf Of Christopher Schultz
>> Sent: Monday, November 4, 2019 13:59 To: [email protected]
>> Subject: [External] Re: [stunnel-users] Extensions when negotiating=20
>> 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=20
>>> application (#1) that uses http2, and isn't encrypted.  No problem =20
>>> here.  Now I have another application (#2) that insists on using=20
>>> https to talk to application #1.  So I gleefully setup stunnel to=20
>>> connect the two.  Well, application #2 starts talking to stunnel with=
=20
>>> a "Client Hello" packet, and it includes an extension "Application=20
>>> 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=20
>>> (application #2) wants to talk "http2" to the server (application=20
>>> #1).
>>
>> Yep, pretty much.
>>
>>> OK, that is what I want.  The problem is that stunnel doesn't respond=
=20
>>> with ANY "Application Layer Protocol Extension" indicating acceptance=
=20
>>> of this request in its "server hello".  This means that application=20
>>> #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=20
>>> 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=20
>> there a requirement that it use h2? Or can it be configured to use=20
>> HTTP/1.1?
>>
>> -chris
>>
>=20


--lnI4q3cFOCBUgPuBzbos2Ys55iLU39l9D--

--Mb8haPc0176MZcZHZqYtis5ax55qON5rN
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3B9XEACgkQHPApP6U8
pFj07w/5ARPzTu32vDBC0EQEc3y2N5v3GDFm9PQgSKWRG39jR0eqLtOHT/JYepeZ
CZJxytxPbyzowr5Bt5avDY4ZA6RaEu5j6JJ+wgkBItgCTtRrInhT0JJhuM7WRwQn
UZOG+Hk+VRZkKEVnrETPO2iC5/XitG1LMYri/Yo/0nRExwuHhaSqvQs4NJI7le1z
WfBiKjWF7r+/iN4eSprktx4IJzDen9+VInBoUFKIwjue+RBBDCKO/f2we7HMXLqn
VbGYan611TUaBtUEah6lzMrQUeZNrFk0xmWhivZAvKgTwnaf6s3sgqUNtUUu8V/+
UulbvgGY4+ich8YYNz+gsUZd6Ro1eBjAd30XX5pOE5DGCYrd9bIhcX0TAig1VuNI
lUlG7fWeJkNdeDqyFBbv3YeFeHJYc5smJI/nU1gZ+7u5vvaZbd7I6P6f78Oc9Q5E
dTLhZj5C02dgOCSqsp/BpaxkVay3MWDDyZkfgkfwh18ddkm5Ubv941akdbPUOZ79
RQwmUX98/1pma9utcQs/mdQI95pzCosVHheSTfwcCKNI751Kuu/3aUXPCmPGt9NX
hxlSKjQLq+DCIZop6EKVYkgcp1xuTyruM0Azb1Zp9jjLLN8UWCcrKaBf9Mpl4mYI
GTWlCsSupGCnFEQm7JQi+VmCQxmD4l9wC2cfbDcNICdZvlzeHsg=
=mtNX
-----END PGP SIGNATURE-----

--Mb8haPc0176MZcZHZqYtis5ax55qON5rN--

--===============5176482814168814665==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

--===============5176482814168814665==--