From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 95F913B29D for ; Wed, 17 Nov 2021 12:35:31 -0500 (EST) Received: from app49.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp2.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3BB93282E for ; Wed, 17 Nov 2021 12:35:31 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app49.wa-webapps.iad3a (Postfix) with ESMTP id 262A5E057D for ; Wed, 17 Nov 2021 12:35:31 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Wed, 17 Nov 2021 12:35:31 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Wed, 17 Nov 2021 12:35:31 -0500 (EST) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20211117123531000000_96025" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1637170531.15339401@apps.rackspace.com> X-Mailer: webmail/19.0.13-RC X-Classification-ID: a8ff01d3-b11a-49bc-be34-eefe3ecc5823-1-1 Subject: Re: [Starlink] something of a step backwardsRE: Starlink Digest, Vol 8, Issue 10 X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2021 17:35:31 -0000 ------=_20211117123531000000_96025 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A> Michael Richardson wrote:=0A>=0A=0A> David P. Reed = wrote:=0A> > The mechanism for MITM'ing HTTPS connect= ions is well known. I don't=0A> > intend to detail it here, but it is based= on the fact that certs aren't=0A> > properly validated by client-end softw= are and server-end software.=0A> =0A> No, this is just not the case.=0A> Wh= ile there are occasionally issues that affect some strange corner case,=0A>= there are no issues in browsers available on any platforms I know of.=0A = =0AWell, I'd suggest reading this. Since I've been following this for years= , I can't testify that these flaws are not fixed on ALL servers, but I real= ly suspect most of these still work, and there are more. In theory, https c= an be made safe from MITM, in practice, theory doesn't tend to apply. (I am= aware of techniques that may work beyond those in this web page, but I don= 't share them until they have known fixes widely published and deployable).= Even HSTS isn't "standard" in nginx, for example.=0A =0A[ https://labs.det= ectify.com/2018/11/29/abuse-mitm-regardless-of-https/ ]( https://labs.detec= tify.com/2018/11/29/abuse-mitm-regardless-of-https/ )=0A =0AI have chosen n= ot to fly for the last two years, so I can't testify whether GoGo Internet = has finally fixed its bufferbloat problem, or whether it intercepts HTTPS w= ith a MITM attack.=0A=0A> =0A> It can only be done in Enterprise cases wher= e the Enterprise uses a=0A> management system to push new anchors. That par= t is "well-known".=0A> =0A> As for blaming protocols when the fault is buff= erbloat, you are definitely=0A> right on.=0A> -------------- next part ----= ----------=0A=0A ------=_20211117123531000000_96025 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Michael Richardso= n <mcr@sandelman.ca> wrote:=

=0A

>

=0A
=0A

> David P. Reed <dpreed@deepplum.com> = wrote:
> > The mechanism for MITM'ing HTTPS connections is well = known. I don't
> > intend to detail it here, but it is based on = the fact that certs aren't
> > properly validated by client-end = software and server-end software.
>
> No, this is just not= the case.
> While there are occasionally issues that affect some s= trange corner case,
> there are no issues in browsers available on = any platforms I know of.

=0A

 

=0A

Well, I'd suggest reading this. Since I've been following this= for years, I can't testify that these flaws are not fixed on ALL servers, = but I really suspect most of these still work, and there are more. In theor= y, https can be made safe from MITM, in practice, theory doesn't tend to ap= ply. (I am aware of techniques that may work beyond those in this web page,= but I don't share them until they have known fixes widely published and de= ployable). Even HSTS isn't "standard" in nginx, for example.

=0A

 

=0A

https://labs.detectify.com/20= 18/11/29/abuse-mitm-regardless-of-https/

=0A

 

=0A

I have chosen not to fly for the last two yea= rs, so I can't testify whether GoGo Internet has finally fixed its bufferbl= oat problem, or whether it intercepts HTTPS with a MITM attack.

= =0A


>
> It can only be done in Enterp= rise cases where the Enterprise uses a
> management system to push = new anchors. That part is "well-known".
>
> As for blaming= protocols when the fault is bufferbloat, you are definitely
> righ= t on.
> -------------- next part --------------

=0A<= /div> ------=_20211117123531000000_96025--