Removing support for outdated security technologies is surely a good move. But
I see your statistics includes only TLS 1.2, so do you have any plan for TLS 1.3? It's the new standard in 2018 and is supported by all major browsers (excl. IE) and a lot of cloud services (Cloudflare, AWS ELB etc.). I really think that should be added as well.
Update May 2017: Stack Overflow is now https by default throughout and not just for login. Thank you, and well done.
The SSL Labs server test scores stackoverflow.com grade A+.
HTTPS should be universal. Why? The status quo of 'http except for ecommerce sites' is dire:
Intelligence agencies are conducting mass survillance (NSA's Prism, GCHQ's Tempora) ...
EDIT: now fixed
When you write "we will be deprecating TLS 1.0 and 1.1", do you mean that they will no longer work after next week?
It seems so from your next sentence, but this is confusing to me, because in my experience that is not what "deprecating" means in the programming world:
While a deprecated software feature remains ...
Thanks again for bringing to our attention about our certificates being affected by the Let's Encrypt CAA Rechecking Bug. Unfortunately, we didn't get any notifications from LE to act sooner, which means you saved us from a potential outage! We went ahead and renewed our certs via DNSControl to our loadbalancers and Fastly.
As seen from the Unbound Test, we ...
Every time I visit https://meta.stackoverflow.com, it shows me that
"This page is trying to load script from unauthenticated pages".
Is there something wrong here?
When I check what is happening in Chrome Developer Tools, this shows up:
Mixed Content : The page at https://meta.stackoverflow.com/questions/345125/suggested-edit-queue-...
Nice work on finally bringing HTTPS support in!
I want to note something on point 4 (emphasis mine):
Rebake remaining posts with HTTP images, so that images linking to HTTP addresses will become links - most of those are dead anyway.
If most of those links are dead anyway, why not go through the hassle once and check if they are actually dead or not. If ...
This is a result/side-effect of some changes Cloudflare made recently, but the fact of the matter is that we'd run into problems with HTTPS support on child meta sites eventually anyway: you can't have a wildcard in the middle of a cert, so meta.*.stackexchange.com could never be a thing and we're not about to start registering/maintaining 100+ certs.
The HTTPS Everywhere extension may cause trouble
…when HTTPS gets forced everywhere (step #10).
The reason is that the HTTPS Everywhere ruleset for Stack Exchange currently contains a forced downgrade to HTTP for all subdomains that are two levels deep, such as *.meta.stackexchange.com.
(You can try this now: install the extension and watch https://...
Area 51 thingies are breaking if you don't add the 's':
Stack Exchange Q&A site proposal: Constructed languages http://area51.stackexchange.com/ads/proposal/101265.png
^with the autogenerated 'share this' link
^manually changing the links from http:// to https://
To clarify: If you go the Area 51 proposal page, and click 'share ...
Don't use HTTPS, we don't fully support it yet. A valid SSL cert is the first step in SSL support, not a flag for it being complete. I'd make a list of what all mixed content is in play, but I'm not sure our max post length is enough.
We intentionally don't link you to HTTPS anywhere that doesn't support it yet...if your browser extensions do so, they need ...
Title for question is not parsed from URL in posts body (at least in preview) if you use https on link or on site where you trying to post. E.g.
open SO via http://
open SO via https://
Link to post was acquired by share button for this question.
This is caused by the switch to HTTPS.
Stack Overflow changed to HTTPS on May 22, and guess what happened. Here are the awarded Announcer badges on Stack Overflow:
This has a technical reason. Visitors coming from within the Stack Exchange network didn't count towards the badge as they were filtered out using the HTTP Referer header. The problem is, HTTPS ...
Running the Immuniweb.com Security Test it complains (abbreviated version):
The problem is TLSv1.1 and TLSv1.0 configured with TLS_RSA_WITH_3DES_EDE_CBC_SHA enabled, that is non-compliant with PCI DSS requirements. In particular, the test complains of supporting TLSv1.0 and lack of support for TLSv1.3. in addition it says: "The HTTP version of the ...
This is a race condition as we upgraded certs immediately but DNS took a bit to catch up. You should now be seeing a valid cert which we'll be updating again as soon as we receive a new combined wildcard for that particular certificate.
Most CAs are a bit busy today which is understandable.
The app is using the Stack Exchange API, which requires HTTPS to be used whenever a user access token is transmitted.
I did an inspection of traffic to/from my phone, and confirmed the app does connect to a Stack Exchange IP address (188.8.131.52) over HTTPS whenever a network based action is taken.
But, I don't have access to the app source code so I ...
We have worked with our CDN provider to roll back a change that was made enforcing OCSP Must-Staple. Firefox should be back in business, sorry for the interruption. To keep up to date follow our StackStatus twitter account:
When accessing one of our MathJax enabled sites via the HTTPS protocol, we now use the CDN specified by the MathJax FAQ:
How do I access the MathJax CDN using a https secure connection?
The MathJax CDN utilizes Rackspace’s CDN service. Unfortunately, this currently does not offer https support for the default address cdn.mathjax.org. However, as an ...
We simply do not support this, and never have. Though it is reasonable to redirect the www. domains on http://, it's not reasonable to do so on https:// (we'd need a truckload of certs). We never generate these links anywhere, that's someone else doing it incorrectly.
It's akin to the meta.*.stackexchange.com problem, all of which are now redirected to *....
CloudFlare seems to have repaired its nginx. Closing as "probably fixed". Will reopen if the bug recurs.
Repro'ed by Gilles:
Still failing for me with all meta.*.stackexchange.com over HTTPS. I guess only some of their infrastructure is broken and we're hitting different entry points. - Gilles (here)
Just repro'ed by myself at Earth Sciences SE meta.
In the Android app, I have Mi Yodeya Meta pinned in my list of sites, and since the switch from meta.judaism.stackexchange.com to judaism.meta.stackexchange.com it has changed to saying Unknown Site meta.judaism instead of saying Mi Yodeya Meta and when I click it the app crashes.
is this the intended design of this special http-to-https edit, or is it rather something that still needs to be addressed somehow?
There is nothing special about the Community edits for the HTTPS link change. The only thing special about those edits is that they don't bump the post to the front page, that's all.
Besides that, they behave like normal edits,...
As pointed out by Davide Cervone above, MathJax CDN does support HTTPS as long as you use the hostname c328740.ssl.cf1.rackcdn.com instead of cdn.mathjax.org. Yes, that looks a bit uglier, but that's all "under the hood".
Thus, this bug can be fixed by replacing the URL:
Yes, SSL support is actively being worked on, and will be completed once they can figure out how to account for all of the pitfalls associated with the transition. My (admittedly uninformed) understanding is that there's no hard timeline in place, just because it's difficult to gauge what it will take to tackle some of the issues.
You can view Nick's ...
Https links will be picked up as linked posts after build rev 2015.2.10.3062 on meta and 2015.2.10.2282 on sites roll out. They will be rendered as relative in the linked sidebar. In the actual post/comment they will still be rendered as they were entered by the author.
Protocol relative URLs are not rendered by the markdown engine as links, I see no need ...
Receiving the https:// error in the Help center - Privileges pages, those contains the images in it. Still the images are as http:// only.
The error is:
In plain text:
Parts of this page are not secure (such as images).
For an example, Create Wiki Posts page contains an image as http://i.stack.imgur.com/aXihi.gif, receiving ...
The edits by Community to change from meta.*.stackexchange.com to *.meta.stackexchange.com are sending all the closed posts that have meta links to the reopen queue because they've been edited. This seems silly since the post wasn't really improved at all.
having an SSL certificate is not expensive anymore, so I can't imagine why we hadn't had it for a long time
Certificates are cheap, but implementing HTTPS on a site that always has run under HTTP is not. There were a lot of issues the team had to deal with: links, images, meta sites, etc.
It is very well possible you've visited Stack Exchange main sites ...
Word on the street is stackpromos.com probably isn't supposed to have a valid cert, but I linked it in the blog post as https out of habit. Will fix as soon as I can get the blog post edited!