Re: [TLS] Possible blocking of Encrypted SNI extension in China

On 7/30/2020 8:45 AM, onoketa wrote: > Hi, > > The Great Firewall of China may have identified and blocked > Cloudflare's ESNI implementation. > > I have found that when using a TLS client hello with ESNI extension to > connect to servers behind Cloudflare's CDN, the connection will be cut > off

[TLS] Possible blocking of Encrypted SNI extension in China

Hi, The Great Firewall of China may have identified and blocked Cloudflare's ESNI implementation. I have found that when using a TLS client hello with ESNI extension to connect to servers behind Cloudflare's CDN, the connection will be cut off after the whole TLS handshake is done. And then

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Peace, On Thu, Jul 30, 2020, 4:39 PM Salz, Rich wrote: > We have a product, site shield, that customers can use to limit the IP > addresses of who can reach their origin server. Everyone else is blocked.. > Some use that to make sure that *only* Akamai servers will talk to them, > and that

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

>In the majority of cases (i.e. delivering preseeded static content), no. It identifies as some-1337-garbage.static.example.com, which it basically *is*. No. That might be the DNS name, but it is not the TLS certificate that the server presents. That certificate MUST have a name

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Peace, On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich wrote: >> It is (in all but a couple of implementations I think) > a *proxy* that the origin has contracted with. Could > you please elaborate on your point? > > It has a TLS cert that identifies itself as the origin. It depends! In the

Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI

On Thu, Jul 30, 2020 at 3:57 AM Watson Ladd wrote: > > > On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis < > yian...@selfienetworks.com> wrote: > >> Hi Ben, >> >> Thanks for your comments. Please find some responses inline. >> >> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: >> >>> This

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

* It is (in all but a couple of implementations I think) a *proxy* that the origin has contracted with. Could you please elaborate on your point? It has a TLS cert that identifies itself as the origin. It doesn’t just terminate TLS, but it does work at the HTTP layer. How is it different

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Peace, On Wed, Jul 29, 2020, 2:20 PM Salz, Rich wrote: > Also, a CDN is not a proxy. It **IS** an entity that the origin has > contracted with to perform certain functions. > It is (in all but a couple of implementations I think) a *proxy* that the origin has contracted with. Could you

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Peace, On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - 0553 - MITLL wrote: > in this particular case, instead of "if you want to do this, then do it > that way, and I'll help you inter-operate" I prefer "if you want to do this > - you're on your own, don't seek a blessing or advice from me". >

Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

I support this draft and agree with the points made below. Paul From: Arnaud.Taddei.IETF Sent: 28 July 2020 09:36 To: Jen Linkova Cc: OPSEC; OpSec Chairs;

Re: [TLS] Network Tokens I-D and TLS / ESNI

On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis wrote: > Hi Ben, > > Thanks for your comments. Please find some responses inline. > > On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: > >> This proposal is highly ossifying. Application protocols that are >> included in this scheme become