Page 1 of 1


Posted: Mon Sep 08, 2014 2:46 pm
by roedygr
I noticed you switched over to HTTPS: for the HtmlValidator website.

I notice all kinds of websites are doing that. I am puzzled why. I would hardly think the content of these sites was embarrassing, confidential etc. HTTPS: defeats caching. What are the advantages?


Posted: Mon Sep 08, 2014 4:22 pm
by Albert Wiersch
I haven't heard anything about HTTPS defeating caching.

I switched over mainly due to Google's promotion of it. See Boost your SE rank by using HTTPS.

I'd say it's part of an "HTTPS everywhere" philosophy. I think there are a lot of reasons why this is a good idea, even if it's just a simply login to something like a forum.

I also solved some issues some people were having with downloading CSE HTML Validator by simply having them download from an HTTPS link instead.

You can get SSL certificates for as low as $5/year, so it's not expensive. :D


Posted: Tue Sep 09, 2014 11:17 pm
by MikeGale
As people become more aware of surveillance by all sorts of people, HTTPS makes more sense.

I imagine the Google initiative is a direct result of this growing awareness. They were especially annoyed when they learned that, despite the access they already gave spy agencies, some of those agencies sneaked in and monitored whole data streams without permission.

Traditional web servers, in my opinion, make HTTPS harder than it needs to be. In addition the X509 certificate system has been degraded by various interests. I think that these shortcomings are already being changed.

Not all web servers are equal. Many have horrible fine grained policies that play right into the hands of those who want to defeat encryption.

The big Achilles heel is mail. No longer suitable, but vey hard to change!


Posted: Wed Sep 10, 2014 8:10 am
by Albert Wiersch
On a related note, Google is pushing to get certificates that use the "dangerously weak" SHA-1. Most certificates do these days. I will probably be working on getting a new certificate using the stronger SHA-2 (or SHA-256) for today.

More: Why Google is Hurrying the Web to Kill SHA-1

Perfect Forward Security

Posted: Wed Sep 10, 2014 7:06 pm
by MikeGale
This link viewtopic.php?f=3&t=1994&p=8647&hilit=p ... ward#p8647, relates.

When I experimented with nice tight definitions on my browser it failed with a lot of sites. Many web sites are effectively hostile to honouring your desire for decent encryption!


Posted: Wed Sep 10, 2014 8:17 pm
by Albert Wiersch
With regards to security and validation, I have recently improved the ability for CSE HTML Validator to warn of links to insecure content (HTTP or FTP) that a secure page (HTTPS) might try to load or include (like insecure images, iframes, external CSS, and external JavaScript). In many cases browsers won't load the insecure content on HTTPS pages, so CSE HTML Validator v15 will now do a better job of detecting insecure content links on secure pages (if CSE HTML Validator knows that the page was loaded or is expected to be loaded with HTTPS).

I've also found it beneficial to use protocol relative links like "//" instead of "" or "". I have considered if I should have some sort of message in CSE HTML Validator about this but am not sure exactly what to say or do about this. I was thinking that perhaps if the page's domain is known (like and there's a link to or to suggest a protocol relative link instead, but there might be a reason for specifying the protocol.

As for sites being hostile to decent encryption, perhaps Google will change that... they seem to be on a path of doing so. You don't want to make Google unhappy as they have so much power. :D


Posted: Thu Sep 11, 2014 6:19 pm
by MikeGale
I think a message about scheme-relative URL's is a good idea.

Many developers don't know about it. Ample evidence is those common browser messages about mixed secure and insecure content.

The message could mention:
  1. Use one protocol (for markup, css, js, images...) independent of markup on page.
  2. The desirability of one protocol. (Will become more important, for users who realise that it's a mess. Given the escalating flood of breaches, Target, Danish Government, South Carolina, Apple... the penny has already dropped for many.)
  3. The problem with multiple ssl domains on one server. (I view that as a design error.) Worth mentioning lest developers get carried away before thinking through the whole situation.
  4. Considerations (maybe) if you're using "file://".
  5. There's probably more...
That would be genuinely useful, even if a bit long.

On the SHA-1 apocalypse, I surmise that the decision arose in industry coordination meetings. Microsoft (in advisory 2880823 published last year) mentions the same date, so the players got together on this one.


Posted: Thu Sep 11, 2014 6:32 pm
by MikeGale
On decent encryption.

(I haven't written a tool to explore this in detail, but a few manual tests paint a poor picture.)

The issues I've seen come from web server config.

Servers are not forced to give you your preferred security suite. If your suite has no overlap they just deliver nothing at all! So the negotiation is a collaboration, of sorts, between browser and server. In one test I was horrified at the insecure options forced on me by a bank! (Said bank has erected a "help desk wall" to actively prevent sensible analyses getting through to management!! Wonderful world we live in!)

There have been investigations of how much this reduces throughput on a server, so there are somewhat quantified measures on the cost.


Posted: Fri Sep 12, 2014 9:58 am
by Albert Wiersch
Hi Mike,

Thanks for your thoughts on scheme-relative URLs. I will have to think about this more.

This seems like a good site to test an SSL/HTTPS server:


Posted: Sun Sep 14, 2014 3:20 pm
by Albert Wiersch
roedygr wrote:I notice all kinds of websites are doing that. I am puzzled why. I would hardly think the content of these sites was embarrassing, confidential etc. HTTPS: defeats caching. What are the advantages?
Here's another reason why one might want to go HTTPS.

Comcast Is Now Working Harder to Annoy Its Customers

If I understand the piece correctly, when someone uses Comcast's free WiFi, they can insert ads into websites where they normally do not appear. I'm not sure exactly how they do this (though the article does say they use JavaScript to insert the ads), but I would expect that HTTPS would stop this nonsense by preventing Comcast from sneaking their stuff in.

UPDATE: Here's a better article: Comcast Wi-Fi serving self-promotional ads via JavaScript injection

I should have gone to the source in the first place. :D

Anyway, that article does say HTTPS will stop it:
One way to prevent this from happening, he said, is for websites to encrypt and serve over HTTPS. But many sites do not do that.
And to top it off, the article says that such JavaScript injection could cause security vulnerabilities that wouldn't otherwise exist, even if there is no malicious intent... and it could also potentially mess up (break) a site as well.

So if you don't want stuff injected into your pages without your knowledge, you may want to pay $5/year for an SSL certificate and go HTTPS.


Posted: Sun Sep 14, 2014 10:18 pm
by MikeGale
That SSLTest link is great.

(The last time I used it, I'm pretty sure it wasn't this good, thanks for the update.)

An ISP injecting JavaScript is insane. I can't believe that anybody, who had a clue what he was doing, would even try that. When your ISP is that much of an enemy we really need to move away from the friendliness of HTTP. This impacts all who make sites.

(If the end user alters content it's different. This sort of thing opens the way for every hop in, say a 20 hop trip, to mangle content.)

What might such lunatics do to your content?


Posted: Wed Sep 17, 2014 7:21 am
by RSteinwand
Albert Wiersch wrote:I've also found it beneficial to use protocol relative links like "//" instead of "" or "".
I did not know that. Thanks! :D I'm using a second domain of ours that supports ssl for my 6 slider images to improve parallel downloads.

Please add that recommendation if you see a hardcoded http or https.

Do a waterfall test on http vs https and you'll find the negotiation for every element is longer. Can easily add a second to two to a page.

We've disabled all unsafe ciphers here when they show on our quarterly scans.


Posted: Fri Apr 22, 2016 4:19 pm
by RSteinwand
We still haven't gone with SSL for our public site, but with HTTP/2 coming, I'm going to ask about it soon.

We're currently blocking unsafe protocols like SSL2 and SSL3 and within the next month TLS1.0 and TLS1.1 will also be blocked. I'm concerned by going to SSL on our public side, we may lose out on new customers on old browsers.


Posted: Fri Apr 22, 2016 9:56 pm
by MikeGale
I have safe browsers where I control the protocols available, through Schannel. If a web site fails on a safe browser it goes to a less safe browser, namely one of those with a paternalistic, you can't control it, strategy. It's horrifying how many banks and the like only implement less desirable security suites.

On a separate issue today I was called in to help with a web site that failed. It didn't work in Firefox, presumably because it was using a deprecated protocol / security suite. Needed to go another browser to see anything on the site. (Firefox seemed to have an unavoidable lockout. Again a paternalist, you're too stupid to decide for yourself, approach.)

Bottom line. This area is a minefield.