Chrome Bug - Force ALWAYS SSL -

Chrome Bug - Force ALWAYS SSL -

from 10 minutes chrome forcefulness ssl certificate in subdomains of website.

my website: https: //www.mywebsite.com -> ssl ok installed

subdomains: http://forum.mywebsite.com -> ssl not installed

now "chrome" forcefulness forum go under ssl, perhaps because visit main site forced ssl, not create sense. on ie, firefox , other versions of chrome nil happens, on pc chrome.

i have no extensions installed, nor antivirus forcefulness secure connections such kaspersky.

this taken 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/"]

in http response https site, hsts in headers.

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

that you're describing; forcefulness parent domain , subdomains https.

edit: here's more detail, interested.

typically, have user come site in http. if want secure connection, redirect them same page, https. problem redirection happens on network, in http, not secure. man-in-the-middle attack can block upgrade, , leave user stuck in http; worse still, might not realize they're beingness attacked. offer site in https-only, users trying site in http think website down, , that's bad too.

so hsts (http strict-transport-security) solution there. it's supported modern browsers (chrome/firefox, think safari, , ie12 have it.) older browsers ignore it.

hsts applied per-domain. 1 time hsts active yoursitehere.com, if user types http://yoursitehere.com browser, browser different; instead of contacting yoursitehere.com using http, rewrites query https before hitting network. mitigates man in middle attack.

there 2 ways turn on hsts. 1 using http response header, must served on https. other contacting browser companies (google, apple, mozilla, microsoft) inquire asking added "hsts preload list", configuration file shipped browser.

if turned on response header, there's 1 additional option; how many seconds should turned on for?

with either method of triggering, there's 1 major option. "includesubdomains", asked about. if includesubdomains set, instead of including yoursitehere.com... include www.yoursitehere.com, mail.yoursitehere.com, static.yoursitehere.com, , on.

this unsafe thing turn on without testing bit first.

moving site https may highlight mixed content errors; browsers set these in console, pop them up, it's https page using http resources. if site supports https time, non-issue.

again, dangerous, because it's by-domain, , not by-path.

so if yoursitehere.com/your-application wants hsts, yoursitehere.com/another-teams-application not, 1 product/server can forcefulness on if they're mapped under same domain.

google (gmail, drive, etc), twitter, facebook, paypal , others have been using awhile.

google-chrome