Re: [Lynx-dev] TLS-"transport layer security" & LYNX

[vines]

> > > manipulating connections, blocking connections that are deemed
> > > "unwanted / illegal / etc.", and spying on user agents.  
> > 
> > That's all very well, and I'm glad it's available.  My beef is with
> > webservers imposing it on clients, rather than letting clients choose.
> 
> The idea is that if the webserver does not impose it the client will not
> get the choice because of the gov./etc., thus the choice is imposed on all
> for those whose clients would not get the choice.
> 
> It is a trade off.
> 


A little late, but, something I wanted to post here:

Apparently, according to https://www.howsmyssl.com my distribution of Lynx is
supporting weak cipher suites, and that is the only problem with Lynx's TLS.
'3DES vulnerable to sweet32'
I think this is something that can be fixed upstream?
Assuming the opinions of howsmyssl.com on cipher suites are credible.


<rant>

Yes, I would conclude HTTPS is one big trade-off, with obvious flaws.

My grudge against HTTPS, for example, is that just looking through an average
certificate store is an enourmous set of public keys - and it would seem to be
impossible to keep up with who actually owns the private counterparts of these.
And it only takes one to be compromised to throw everyone's HTTPS verifications
off.

So I try to think of HTTPS as a 'public beta' - consumers have only just moved
to the internet for everything over the past 10 years, and there are various
developments that need to happen to it. I too dislike the power of Google, but
they are introducing a new security header named 'Expect-CT' which _might_ solve
the thing I most dislike about HTTPS. It should be easier to implement than
HKPK. But at present the 'Secure' and 'NotSecure' notices in Chromium/Chrome are
just oversimplified humour!

But maybe one day HTTPS will be more robust, safe.

Personally I think physically going to a business and being given a copy of 
their
key would be good... a mix of old and new.

</rant>