Re: [Starlink] something of a step backwardsRE: Starlink Digest, Vol 8, Issue 10

Re: [Starlink] something of a step backwardsRE: Starlink Digest, Vol 8, Issue 10

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]


> Michael Richardson <mcr@sandelman.ca> wrote:
>

> 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 strange corner case,
> there are no issues in browsers available on any platforms I know of.
 
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 theory, https can 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.
 
[ https://labs.detectify.com/2018/11/29/abuse-mitm-regardless-of-https/ ]( https://labs.detectify.com/2018/11/29/abuse-mitm-regardless-of-https/ )
 
I have chosen not 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 with a MITM attack.

> 
> It can only be done in Enterprise 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
> right on.
> -------------- next part --------------


[-- Attachment #2: Type: text/html, Size: 5360 bytes --]