bug-ed
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-ed] Project page HTML validation link broken


From: Bob Proulx
Subject: Re: [Bug-ed] Project page HTML validation link broken
Date: Sat, 5 Aug 2017 15:52:34 -0600
User-agent: NeoMutt/20170609 (1.8.3)

Hi Antonio,

Antonio Diaz Diaz wrote:
> Bob Proulx wrote:
> > I like it.  Using "https:" is certainly always safe.
> 
> Sadly I have discovered that even if "https:" is always safe, it not always
> works on (not so) old browsers:

I think this is really a completely separate problem.  One of
obsoleting insecure encryption protocols.  And in the browser rather
than the server.

For example I have an old "Tomato" based WRT54g router in use at a
remote location.  Tomato is an old distribution.  It pre-dated support
for TLS and the latest it has is SSLv3.  Now that SSLv3 is deprecated
and removed from currently supported browsers I can no longer use a
modern browser to communicate with it using https.  I can still talk
to it using an old browser from a chroot that still includes support
for the old protocol.  I need to replace that old and now insecure
Tomato based box with something supported with continuing updates.

> "As of May 07, 2017 the Fossies server fossies.org is now only be accessible
> by HTTPS using the modern TLSv1.2 protocol to make sure the exchanged
> information and data are always protected.

That seems very agressively secure of them.  Certainly TLSv1.2 is the
best protocol widely available at this time.  But AFAIK 1.1 hasn't
been broken to the point of being avoided.  Currently supported
browsers should have mitigated the BEAST attack against 1.0.

Here is a good reference.

  https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

> Given that the "valid html" button is not a required feature of the ed page,
> and the problems it has already caused, I have finally removed it. Sorry for
> the inconveniences.

Well...  It is an optional feature.  And given that you are probably
tired of dealing with it then avoiding it by removing it seems
perfectly reasonable.

But the "//" reference version does work just fine too, right?
Because if one's browser is too old to connect using https then it
will be using http and then the URL using "//" will do the right thing
in either case.  And if new enough to connect using https then "//"
again will do the right thing.  Or at least is working okay for me in
my usage of it. :-)

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]