user3477026
user3477026

Reputation: 241

Chrome Bug - Force ALWAYS SSL

From 10 minutes chrome force the SSL certificate in the subdomains of my website.

My website: https: //www.mywebsite.com -> SSL OK INSTALLED

Subdomains: http://forum.mywebsite.com -> SSL NOT INSTALLED

Now "chrome" force my Forum to go under SSL, perhaps because always visit the main site where it is forced SSL, but it does not make sense. On IE, Firefox and other versions of Chrome nothing happens, only on this PC with Chrome.

I have no extensions installed, nor antivirus that force secure connections such as Kaspersky.

This is taken from a Log: chrome: // net-internals / # events

17239: URL_REQUEST 
http://forum.mywebsite.com/ 
Start Time: 10/24/2014 22: 14: 16,596 

t = -633,892 [st = 0] + REQUEST_ALIVE [dt =?] 
                   -> Has_upload = false 
                   -> Is_pending = true 
                   -> Load_flags = 3384432 (BYPASS_DATA_REDUCTION_PROXY | main_frame | MAYBE_USER_GESTURE | VERIFY_EV_CERT) 
                   -> Load_state = 0 (IDLE) 
                   -> Method = "GET" 
                   -> Status = "SUCCESS" 
                   -> Url = "http://forum.mywebsite.com/" 
                   -> Url_chain = ["http://forum.mywebsite.com/","https://forum.mywebsite.com/"]

Upvotes: 4

Views: 727

Answers (2)

Dean J
Dean J

Reputation: 40349

In an HTTP Response from the HTTPS site, look for HSTS in the headers.

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

That would do what you're describing; it could force the parent domain and all subdomains to always be HTTPS.

Edit: here's more detail, for those interested.

Typically, you have a user come to your site in HTTP. If you then want to secure their connection, you redirect them to the same page, but HTTPS. The problem with that is that the redirection happens over the network, in HTTP, which is not secure. A man-in-the-middle attack can block the upgrade, and leave the user stuck in HTTP; worse still, they might not realize they're being attacked. You could offer your site in HTTPS-only, but then users trying your site in HTTP would think your website was down, and that's bad too.

So HSTS (HTTP Strict-Transport-Security) is the solution there. It's supported by most modern browsers (Chrome/Firefox, I think Safari, and IE12 will have it.) Older browsers ignore it.

HSTS is applied per-domain. Once HSTS is active for yoursitehere.com, if a user types http://yoursitehere.com into a browser, the browser does something different; instead of contacting yoursitehere.com using HTTP, it rewrites the query to HTTPS before hitting the network. This mitigates a man in the middle attack.

There are two ways to turn on HSTS. One is using a HTTP Response header, which must be served over HTTPS. The other is by contacting browser companies (Google, Apple, Mozilla, Microsoft) ask asking to be added to the "HSTS preload list", which is a configuration file shipped with the browser.

If this is turned on with a response header, there's one additional option; how many seconds should this be turned on for?

With either method of triggering, there's one major option. "includeSubDomains", which was asked about. If includeSubDomains is set, instead of just including yoursitehere.com... it would also include www.yoursitehere.com, mail.yoursitehere.com, static.yoursitehere.com, and so on.

This is a dangerous thing to turn on without testing a bit first.

Moving a site to HTTPS may highlight mixed content errors; some browsers put these in the console, some pop them up, but it's an HTTPS page using HTTP resources. If your site already supports HTTPS all the time, this is a non-issue.

Again, this is also dangerous, because it's by-domain, and not by-path.

So if yoursitehere.com/your-application wants HSTS, but yoursitehere.com/another-teams-application does not, one product/server can force it on for everyone if they're all mapped under the same domain.

Google (Gmail, Drive, etc), Twitter, Facebook, Paypal and others have been using this for awhile.

Upvotes: 6

Nathan Stocks
Nathan Stocks

Reputation: 2164

Perhaps the server is sending a redirect to this particular browser because of how it identifies itself.

If you open the developer inspector and run your query, what return code to you receive from your initial request?

Upvotes: 0

Related Questions