Update 2017-05-22

stackoverflow.com is now https://. I've written up a lot of what it took to get here in a blog post. Next up is chat and then https-only cookies. We'll be ramping up HSTS max-age directives as we go. I'll continue to update this post as we deploy new bits.


Update 2017-03-16

We've redirected all child meta traffic from meta.*.stackexchange.com to *.meta.stackexchange.com, and are now forcing HTTPS. We have also rebaked links inside the network (except comments) to point to the new domains and protocol. We'll get to comments at the end.

We are aware of HTTPS Everywhere users getting too many redirects here, and unfortunately the issue is with their ruleset. I have submitted a PR to resolve this here: EFForg/https-everywhere/#9110

We are pausing further migrations while we observe how google handles sites like Super User over the next week or so. I'll be back from vacation on March 27th and we plan to deploy Content-Security-Policy-Report-Only headers for reporting and proceed with full Q&A deployment across all main sites then.


Initial post

This is a heads up, and a request for help. Related: original post from our test site, Meta Stack Overflow.

HTTPS for our entire network is long overdue, but we've been working hard on it behind the scenes. Expect a pretty big blog post when we turn it on everywhere that details the journey.

There are a few lingering questions on HTTPS we're not confident in until we do it live. One of these is the Google site move in webmasters. It still (to our disbelief) treats HTTP and HTTPS as different properties. I have no idea why. And the "change of address" tool doesn't support such a move either:

Note: The tool does not currently support the following kinds of site moves: subdomain name changes, protocol changes (from HTTP to HTTPS), or path-only changes.

So we'll have to create property sets for every single site during the move to HTTPS. Fun!

Given the above, we need to see how all of this works in practice with real load:
We're starting with meta.stackoverflow.com and meta.stackexchange.com.

Here's an order of things that's been going on (per site):

  1. done Infrastructure in place:
    • A fast CDN/Proxy for local termination (Fastly)
    • Certificates (including IP pooling support to bridge HTTP/1.1 & HTTP/2)
    • Logging
  2. done Get third-party support in place:
    • All per-site scripts onto our CDN and served securely
    • Ad providers to HTTPS
  3. done Fix a ton of code that assumes http:// in a million places.
  4. done Prevent users from embedding new http:// content (e.g. forcing HTTPS images).
  5. done Cleanup all existing user content that was http:// (https:// where possible, and converted to links if we can't embed it securely).
  6. done Make sites render absolute URLs as https://.
  7. done Move canonical URLs to https://.
  8. done 301 Traffic to https:// for all.
  9. done (Child metas) Move from meta.*.stackexchange.com to *.meta.stackexchange.com.
  10. Force all Q&A traffic to https:// (and set an https-only cookie)
  11. Migrate all existing sessions to secure sessions (this will take time to run).
  12. Use HSTS to ensure browsers don't hit Q&A sites via http:// at all.

This is a really high level list, and there are a crazy number of nuances and edge cases to the above. This is for Q&A. Area 51, Chat, and stackexchange.com (the main site) have a separate set of concerns and code we'll address after Q&A. The list also isn't necessarily in order. While we're testing #6, Samo and I will be working on #11 at the same time.

But we have to do all of this across the network, and we're starting that process now. meta.stackoverflow.com was our testing ground this week. While we're still waiting for Google's analytics to catch up so we can assess impact, we're ready to go on a few more sites. Here's our rough list:

  1. done meta.stackoverflow.com
  2. done meta.stackexchange.com
  3. done security.stackexchange.com (why? This community is well equipped to test HTTPS concerns and give feedback)
  4. done meta.security.stackexchange.com (moving to security.meta.stackexchange.com)
  5. stackoverflow.com
  6. done Q&A network main sites except stackoverflow.com (e.g. *.stackexchange.com, superuser.com)
  7. done Stack Overflow localized child metas (e.g. meta.ja.stackoverflow.com moving to ja.meta.stackoverflow.com)
  8. done Q&A network child meta sites (e.g. meta.*.stackexchange.com)
  9. done stackexchange.com (the top level non-Q&A domain)
  10. done area51.stackexchange.com
  11. (Planning required) chat.stackoverflow.com, chat.stackexchange.com, and chat.meta.stackexchange.com

We want your help simply reporting any issues with insecure content on https:// or any other oddities you see. We'll try to address them as soon as possible. Since we get asked this a lot, yes - I'll write an exhaustive blog post about everything we hit along the way when we're finished here.

  • 10
    For 11. chat, how about you migrate chat.so to chat.se and have a problem less? – Braiam Mar 8 '17 at 14:51
  • 19
    @Braiam That's not really a problem less, it's the same solution for all 3. However, it would create a ton of problems merging 3 databases, room lists, users, code assumptions, figuring out redirects for all time, etc. It's just not a win in any way :) – Nick Craver Mar 8 '17 at 14:52
  • 1
    On the Google thing, they made this big deal about how it helps SEO and yet there's no indication it helps much, if at all. So the fact that WMT doesn't support it correctly doesn't surprise me either. Google wants HTTPS, but not badly enough to make it easier for people to make it work – Machavity Mar 8 '17 at 15:00
  • 8
    Do you want bug reports as answers to this, separate questions tagged bug and ssl, or something else? – ale Mar 8 '17 at 15:20
  • 7
    There's a minor content security-related bug for the editor preview that may have been missed for #3. TO THE WHEEL OF BLAME! – Tim Stone Mar 8 '17 at 15:25
  • 6
    @ale Answers here are fantastic, thanks! – Nick Craver Mar 8 '17 at 15:30
  • 1
    The Hot Meta Posts (on meta.SO itself) are not linked with https (not sure if caching, but it's been a while). – Floern Mar 8 '17 at 17:04
  • 2
    How are you planning on moving the metas to site.meta.se? Will you have the Community bot go around editing them, or will that be on the users to edit their posts? – Riker Mar 8 '17 at 17:35
  • 1
    @NickCraver I'm getting sticky HTTPS from here on MSE to other sites. E.g. I come here and it rewrites the URL to HTTPS, I use the supercollider to go elsewhere, URL stays HTTPS, and then when I go to that other site's meta I hit the cert error. I gather that's not intended behavior? I'm seeing it in Firefox 51.0.1 and reproduced in a private window. I am not using the HTTPS Everywhere extension. – Monica Cellio Mar 8 '17 at 22:46
  • 3
    Followup: doesn't happen on Chrome 56.0.2924.87. Maybe a Firefox bug? (I'm not sure I want to use IE to break a tie...) – Monica Cellio Mar 8 '17 at 22:52
  • 1
    @PeterMortensen What's "this"? Pretend I know nothing about your super secret always-encrypted programming language :) What's breaking? Does the lib not support HTTPS at all or something? Or...another issue? – Nick Craver Mar 9 '17 at 1:30
  • 1
    Answer: it's SOUP. – Monica Cellio Mar 9 '17 at 3:12
  • 1
    @PeterTurner Nick's kind undeletion aside, I think it was correctly deleted, as it does not answer the question which is looking for specific technical issues with SE's HTTPS rollout. It would be more appropriate as a separate meta question than as an answer here. – Xander Mar 10 '17 at 17:13
  • 1
    You might want to add a Content-Security-Policy-Report-Only header so that users will automatically report mixed content and similar issues. You could also add an upgrade-insecure-requests CSP header, though that's not ideal until you're done with everything else. – Brian Mar 11 '17 at 20:25
  • 1
    @John It's not completed yet -- they still have to migrate SO, stackexchange.com, Area 51, and chat. They also need to do #10-12 on the first list. – NobodyNada Mar 30 '17 at 1:50

40 Answers 40

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-is-full?cb=1 was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint ws://qa.sockets.stackexchange.com/. This request has been blocked; this endpoint must be available over WSS.

UPDATE

It also gives the same thing on https://meta.stackexchange.com:

  • FWIW, with HTTPS Everywhere on Firefox and loading that exact question URL, I get Firefox can't establish a connection to the server at wss://qa.sockets.stackexchange.com/. in the Firebug console. – Michael Kjörling Mar 8 '17 at 17:42
  • 2
    Apparently, **www.**meta.stackoverflow.com doesn't load for me, but removing the www. makes it load just fine – Cows quack Mar 8 '17 at 17:59
  • @MichaelKjörling FWIW means? – Suraj Jain Mar 8 '17 at 18:46
  • 1
    @SurajJain FWIW = For Whatever It's Worth. – Michael Kjörling Mar 8 '17 at 18:52
  • 15
    I'm not sure this is an issue, since that site never existed. None of our domains are on www. (and we redirect from it if you try on the second level domains). Basically: this is nothing new, that domain isn't even in DNS. – Nick Craver Mar 8 '17 at 19:24
  • @NickCraver what di you mean by none of domain are on www? – Suraj Jain Mar 8 '17 at 21:52
  • 2
    @NickCraver Actually as you can see in image , it give the issue when visited on non www. – Suraj Jain Mar 8 '17 at 21:55
  • @SurajJain I mean we don't use www. prefixes, we sometimes redirect from them to be handy, but that's it. I'm not sure why your secure websockets (wss://) are blocked or breaking (separate issue), but I've disabled insecure websockets (ws://) for the network in prep for the global move. Are you seeing the issue anymore? – Nick Craver Mar 9 '17 at 0:41
  • @NickCraver What was really happening ? I am not seeing it anymore , What did you do ? – Suraj Jain Mar 9 '17 at 16:13
  • @NickCraver If you see in the image it was insecure socket ws not wss, that means on the site insecure socket was blocked secured are allowed – Suraj Jain Mar 9 '17 at 16:16
  • @NickCraver The page at meta.stackoverflow.com/questions/345125/… was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint ws://qa.sockets.stackexchange.com/. This request has been blocked; this endpoint must be available over WSS. You disabled the insecure websockets after my answer ?? – Suraj Jain Mar 9 '17 at 16:23
  • @SurajJain insecure sockets are disabled across the network now, yes. Since they'd only result in mixed-content warnings everywhere soon. They were already only a fallback, but an invalid one going forward. – Nick Craver Mar 10 '17 at 23:41
  • @NickCraver Just a question i did not understand what do you mean by they were only a fallback, but an invalid one going forward. – Suraj Jain Mar 11 '17 at 17:17
  • 1
    @SurajJain "only a fallback" means that ws:// would already only be used if wss:// cannot be used for some reason. Now that ws:// by design no longer works at all, if wss:// cannot be used, there is no point in even trying ws://. – hvd Mar 11 '17 at 18:00
  • 1
    @Avamander HSTS: yes, after the move. HPKP: maybe, there's a lot in play there (with subdomains) that's very tricky. More to think through there. – Nick Craver Mar 16 '17 at 0:28

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://security.meta.stackexchange.com get downgraded to HTTP.)

Here is the offending rule:

<!-- https links from other pages to these will cause MCB for important elements, hence the downgrades -->
<rule from="^https://([\w.-]+)\.([\w-]+)\.stackexchange\.com/" 
    to="http://$1.$2.stackexchange.com/" downgrade="1" />

Somebody probably needs to send a pull request with a fix (I might do this myself if I've got time for it) and it might be a good idea to wait until the fixed rule is in HTTPS Everywhere before you initiate step #10.

Edit: I dug trough the HTTPS Everywhere source a bit, and it does contain some logic to detect redirect loops; so, even with the downgrade rule in it, it should eventually give up and allow the HTTPS site to load.

  • 2
    Is this what is causing the security.meta.stackexchange.com redirected you too many times. error I get when I try to view the site in Chrome? – Kodos Johnson Mar 14 '17 at 19:09
  • I have HTTPS Everywhere on Firefox and did notice this bug at first but now no longer and it properly serves me the HTTPS version. – SEJPM Mar 14 '17 at 20:01
  • 8
    I will be submitting PRs to the extension as we make network changes. – Nick Craver Mar 14 '17 at 20:36
  • 2
    I've opened a tracking issue. – Bardi Harborow Mar 15 '17 at 6:11
  • 4
    A PR has been submitted here: github.com/EFForg/https-everywhere/pull/9110 – Nick Craver Mar 16 '17 at 19:39
  • @NickCraver Glad to see you could get a fix in. I noticed a few oddities, though: 1. You're excluding meta.*.SE here, wouldn't it make a lot more sense to rewrite it to https://$1.meta.stackexchange.com instead? (Your pull request only rewrites https://meta.*.SE, not http://meta.*.SE) 2. You might want to add a <securecookie> for *.meta.SE 3. Might want to add a rewrite rule for meta.*.SO once those are ready. Anyway, 👍 for your efforts – user2428118 Mar 17 '17 at 20:34
  • @user2428118 good points - to be honest I really only focused on fixing the immediate redirect issue. Since we'll be all HTTPS and using HSTS with secure cookies after the rollout, the end game is to just delete the vast majority of that ruleset. When we're totally done (chat, etc.), we should be able to delete it completely. Even things like elections.se.com are being moved to another domain (anyone have any suggestions?) for cookie security. The second level domain cookies should only hit our network at the end, all third-party services are being moving off. So much to do :( – Nick Craver Mar 18 '17 at 14:04
  • @user2428118 To be clear: I very much welcome anyone cleaning up the rules further in the meantime (and I'll help them with as much information as possible), but I think my main efforts should be towards eliminating it. If someone is coordinating changes, ping me via @NickCraver on GitHub and I'll gladly answer any questions or review anything I can. – Nick Craver Mar 18 '17 at 14:15
  • 1
    @NickCraver, your comment doesn't make clear whether you are aware of this: the policy of HTTPS-Everywhere is to delete rules only when the domain is preloaded. HSTS alone isn't enough. – Droplet Mar 21 '17 at 22:22
  • @NickCraver Pull Request is merged, It is completed. shall we mark it as status-completed. – Suraj Jain May 28 at 16:50

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

Stack Exchange Q&A site proposal: Constructed languages

^manually changing the links from http:// to https://

To clarify: If you go the Area 51 proposal page, and click 'share this', and copy the embedded ad, post that somewhere on the SE network, the image will not show - it'll be a link, but not an image, as seen above. If you edit the links in the ad to have https:// instead of http://, the image shows up.

This appears to have been caused by 4.) on the list, because it's embedding an http:// link.

  • Which page are you referring to? Area 51 isn't enabled for HTTPS yet, as indicated in step 10 above :) – Nick Craver Mar 8 '17 at 19:52
  • @Nick if you go to the Area 51 proposal page, and get the thing for the ad, it doesn't show the image, at least on SE. I'm pretty sure this is left over from the image switch. I'm going to see if it still works outside of SE... – Mithrandir Mar 8 '17 at 19:53
  • So you're talking about visiting https://area51.stackexchange.com? If so, that's not supposed to work yet...see step 10 above. It's another codebase much more easily moved after the network (since we can assume HTTPS everywhere, at that point). – Nick Craver Mar 8 '17 at 19:54
  • I don't know. I tried to post an Area 51 embedded ad link, as an answer and... it was broken until I edited the links to say https://. – Mithrandir Mar 8 '17 at 19:56
  • @NickCraver I edited to clarify. – Mithrandir Mar 8 '17 at 20:00
  • 2
    Ahhhh, I understand the issue now - sure I can fix that piece of Area 51 real quick - stand by. – Nick Craver Mar 8 '17 at 20:01
  • 3
    If you do a hard reload of the Area51 page (to get new JavaScript), it should render an https:// image to embed now. Cache breakers are also something I'll have to address in that ancient code later... – Nick Craver Mar 8 '17 at 20:14
  • bolded the https and http, looks more readable now. is it ok ? – Suraj Jain Mar 22 '17 at 2:46
  • @NickCraver How about correcting links in posts by community user? – Pandya Mar 25 '17 at 6:13


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://

    https only not parser

  • open SO via https://

    all of not parser

Link to post was acquired by share button for this question.

  • Related ? – Arulkumar Mar 9 '17 at 14:37
  • 1
    The share buttons will switch to https:// as the site they're on does. For example, share links on this post are https://, while Stack Overflow isn't yet. – Nick Craver Mar 9 '17 at 14:45
  • 1
    @NickCraver share link for current question is not parsed in preview. – alexolut Mar 9 '17 at 15:21
  • @Arulkumar possibly a duplicate. – alexolut Mar 9 '17 at 15:42
  • 4
    +1 for the freehand circles. – DavidB Mar 10 '17 at 3:20
  • @alexolut Ah - I gotcha on the actual issue, noted for fixing, will try and do so first thing Monday. – Nick Craver Mar 10 '17 at 21:52
  • Eh, it was bugging me. A fix is rolling to production now, thanks for the info! – Nick Craver Mar 10 '17 at 22:30
  • 1
    @NickCraver the problem of HTTPS links not getting titles is still happening, though – muru Mar 11 '17 at 8:13
  • @muru That should be fixed now - and the child/meta/parent relationships will be fixed in a deploy tomorrow (I'm just deep in a CSP header branch/refactor at the moment). – Nick Craver Mar 14 '17 at 20:33

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.

  • 1
    Working on pushing a fix so people don't have to do this manually, but for now you'll need to log out completely in the app and log back in (it requests the list of all sites from the Stack Exchange API on login). – Kasra Rahjerdi Mar 16 '17 at 19:23
  • 2
    Manually removing and re-adding it will also fix the issue. – SEJPM Mar 16 '17 at 22:09
  • @KasraRahjerdi - Any update on the auto fix? Just got a new report on Arqade: gaming.meta.stackexchange.com/q/12333/28182 – Robotnik Mar 30 '17 at 3:27

Won't this breaks thousands of old JavaScript snippets that are referencing external scripts by http? Example: (note: I suspect no one is linking to jquery using http but it's at least shows the issue)

$("#test").text("hello world");
<script src="http://cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js"></script>
<div id="test"><div>

error message showing http references no longer work

The majority of questions related to JavaScript libraries reference external scripts. Three.js, Pixi.js, etc...

Here's a script that attempts to find snippets that have http references. It also lists mentions of jsfiddle, codepen, jsbin in case you want to move them to a snippet

  • For the moment, that only happens when hitting the "run code snippet" button (and not load)...we still have to figure out long-term on mixed content there. – Nick Craver Mar 13 '17 at 14:09
  • 2
    You should use protocol-inferred urls: //cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js – programmer5000 Mar 13 '17 at 21:02
  • 6
    @programmer5000 it's really better to use https://, which is HTTP/2 and faster in most cases there. – Nick Craver Mar 14 '17 at 1:51
  • @NickCraver, what's the difference? I thought using // means "use the same protocol as the page. The browser will add https: to the request. So what's the important difference (not that I have anything against using https:// instead of just // it's just AFAICT the result for SO will be the same. – gman Mar 14 '17 at 15:08
  • 1
    @gman a) they're harder to deal with - there's a lot of code and assumptions that are harder, and b) in a http:// context, they won't be delivered over HTTP/2, which is faster. – Nick Craver Mar 14 '17 at 20:35
  • If you are on https://example.com and there's a content at //example.com/*, doesn't it use http/2 either way? – Umur Kontacı Mar 14 '17 at 22:37
  • You also have the potential issue of the site being linked to not supporting SSL at all. Rewriting all HTTP URLs to HTTPS would break all HTTP links that do not support HTTPS. – jduncanator Mar 14 '17 at 23:33
  • I would extend it to all links to sites like lorempixel.com, often used for HTML and CSS snippets. But being able to do gUM in snippets for chrome is a good thing ;-) – Kaiido Mar 16 '17 at 11:20
  • @nick This was just a suggestion for sites that are being built with http for now but will move to https, to ensure a smooth transition. For many sites (such as my own, https://programmer500.com) https was a long term goal but not achievable immediately. I definitely support https. – programmer5000 Mar 18 '17 at 13:53
  • 2
    @programmer5000 We had relative links...they actually made the transition much more painful due to: what's relative? what's not? what's http? what's not? what has a valid cert? what doesn't? JS complications in checks, the same paths being unusuable in other contexts (e.g. emails and mobile apps). There are many downsides - I wouldn't advise that intermediate step for anyone else after doing it ourselves :) For a simple website (e.g. only a website), it can be a net positive, but with other pieces, it gets pretty complicated fast. – Nick Craver Mar 18 '17 at 13:58


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:

Https error

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 warning due to this.

  • 3
    Noted - I've fixed this one but we'll have to address the help center globally - thanks! – Nick Craver Mar 9 '17 at 15:18
  • @NickCraver "fix help center globally" there's a similar problem here: meta.stackexchange.com/help/privileges/approve-tag-wiki-edits - should we hold off on making issues with the help center for now? – vcsjones Mar 10 '17 at 20:19
  • 1
    @vcsjones Hmm privs need some more love. I just did all content/localized posts across the network, but privileges will need another code backfill for re-publishing. Noting down for Monday, thanks! – Nick Craver Mar 10 '17 at 21:51
  • 1
    @vcsjones These should be resolve now - are you seeing any more? – Nick Craver Mar 13 '17 at 12:36
  • @NickCraver did some clicking around and looks good so far. – vcsjones Mar 13 '17 at 13:54

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.

  • this is fixed now, edits on posts by community are excluded from queue the criteria – m0sa Mar 17 '17 at 10:27
  • 4
    What about anonymous suggested edits? – Double AA Mar 17 '17 at 11:20
  • @m0sa, pinging you for the above comment regarding suggested edits. – chirlu Mar 28 '17 at 22:23

Once a number of comments are posted under a question or answer, the option will be offered to convert the comment thread into a chatroom:

Please avoid extended discussions in comments. Would you like to automatically move this discussion to chat?

Once a user confirms that, a new comment appears:

Let us continue this discussion in chat.

This link is still HTTP (though you'll be redirected to HTTPS automatically, unless the room has been deleted in the meantime, in which case you get a strange 'Object moved' 404 error page). Oh, and if you get to fix this, it's only a minor effort to implement this feature request.

Seems that protocol-inferred urls i.e. that begin with // have not been changed by Community ♦ user via auto-fix.

E.g. in the post on ruSO.meta link:

//meta.ru.stackoverflow.com/questions/305/

should have been changed to:

//ru.meta.stackoverflow.com/questions/305/

But it wasn't. Using links from revision 4 leads to opening page with unsecure connection warning message.

Urls with explicit protocol using were succesfully changed, you could see it e.g. here.


In the Area51 proposal page for Qubes, after I commited,

enter image description here

  • Yep - we haven't done this yet - it'll come later in the list #10 – Nick Craver Mar 13 '17 at 12:38

From Example newsletter popup is empty...

The example newsletter from the "Love this site?" ad is loaded (and blocked) in an iframe over HTTP, so all you see is a blank white lightbox/popup/dialog/whatever-you-want-to-call-it:

enter image description here

Seems the newsletter page itself does support HTTPS so changing the link to HTTPS fixes it:

enter image description here

  • Got it, will fix Monday - thanks! – Nick Craver Mar 12 '17 at 0:35
  • This will be fixed as cache expires over the next hour. – Nick Craver Mar 13 '17 at 12:36
  • @NickCraver still not working for me. – alexolut Mar 20 '17 at 3:11
  • @Nick still broken in the Edit Profile preferences section: i.stack.imgur.com/o2UmC.png can you please fix it there as well? – Shadow Wizard Mar 20 '17 at 9:00
  • @ShadowWizard 2 months gone and problem still exists despite of status-completed – alexolut May 27 '17 at 7:58
  • @alexolut not really, the problem described in this answer is fixed (hence the status-completed tag is correct), what you found is a different problem, as it happens in a different place. Since Nick ignore our comments here, you can post a new bug report about it. – Shadow Wizard May 27 '17 at 13:44
  • @ShadowWizard different problem with same behavior? – alexolut May 27 '17 at 13:46
  • @alexolut exactly. Normally such two bug reports would be closed as duplicate, but we're dealing with only an answer here, with "non standard" way of marking it as completed. – Shadow Wizard May 27 '17 at 13:47

Regarding SSL and Web server Security I have some knowledge, but instead writing paragraphs upon paragraphs of information about this, I will refer all who this may concer to the following link:

This website uses other websites such as - but not limited to - SSL LABS, and HTbridge

Currently the score of meta.stackexchange.com is an "F":

observatory.mozilla.org

  • 8
    Yeah to be honest I'm not worried about this, at all. You're testing the very first phase of a many part move, the fact that all the pieces aren't in place is expected. The first phase is getting onto HTTPS for all traffic, which is better scored here: ssllabs.com/ssltest/… As an example, if I turned on Secure only cookies instantly without a migration, I'd log out millions of users. I happen to think that's a bad idea :) – Nick Craver Mar 14 '17 at 20:42
  • 1
    OTOH SSL Labs reports A. – Martin Schröder Mar 14 '17 at 21:16
  • [status-deferred] then? – Robotnik Mar 16 '17 at 0:21
  • I get D- for meta.stackexcange.com, and F for StackOverflow?? – SteveFest May 1 '17 at 7:53

The total page views from the moderators dashboard in Meta does not show any data before Mar 16 2017, the day the switch to *.meta.stackexchange.com was done.

On most stackexchange.com domains, you are automatically being redirected from HTTP to HTTPS. E.g. http://meta.stackexchange.com leads to https://meta.stackexchange.com.

There are at least three subdomains for which this isn't the case:

Are there any plans to change this, or is this ?

I am currently getting certificate warnings on When reviewing a suggested edit, how do I tell what question or answer it relates to? from Chrome, but weirdly am not getting them visiting https://meta.security.stackexchange.com directly:

enter image description here

  • 2
    You loaded up before it was ready :) See the list in the post - we're not to child metas yet. However, we're starting that today, and security.meta.stackexchange.com is first up. – Nick Craver Mar 13 '17 at 14:10
  • 1
    Can you still reproduce this bug? – SEJPM Mar 14 '17 at 20:03
  • @SEJPM No it seems to be working now. The little "not secure" is gone on the security meta too now. – Jason C Mar 14 '17 at 21:46

Share links from sites accessed via HTTP still give HTTP links (sort of, actually it's inconsistent: MSE always seems to give HTTPS, SO always seems to give HTTP), which makes sense, except you might want to consider forcing them to give HTTPS links instead because:

  • There's a ton of HTTP links that exist into the sites still (for example, Google links mostly go to HTTP, old browser bookmarks and autocompleted URLs, etc.), meaning lots of people getting non-https share links.
  • This will help reduce the load of HTTP → HTTPS conversions in posts.

There is some pretty compelling evidence for this. On SO, for example, since March 10 (the date of this announcement), and as of about 8 hours ago (good timing on the SEDE update):

  • 7,938 posts have been created that have a link to stackoverflow.com in some form.
  • 7,616 of those use HTTP and not HTTPS.

That's a whopping 96% of new SO-link-containing posts that end up having HTTP links in them.

To be clear, that's not to say that all of those are a result of share links. Those numbers are evidence that a lot of people are visiting via HTTP (because the links they post will either be share links or copy + pasted from their browser bar). But to me, it follows that share links should probably be converted.

SO was used as an example, I presume the pattern is similar elsewhere.

There is an old feature request about this here that should probably be revisited.

To that end you probably also want to start serving redirects at some point from the HTTP pages to HTTPS. That'll take care of the "copy link from address bar" end of things, plus all the external HTTP links that you have no control over.

  • 2
    On sites that are HTTPS default, the share links are HTTPS. It's not dependent upon you you accessed the page, they (intentionally) match the canonical. They'll shift over as the site does. – Nick Craver Mar 20 '17 at 12:21
  • @NickCraver Ah I see, so SO isn't shifted over yet (which aligns with lack of done next to item 5 in your second todo list)? That's why the links are still HTTP there, right? I can see that MSE and MSO all have HTTPS share links, which also lines up with the progress lists you've posted. – Jason C Mar 20 '17 at 21:12

: moved to https://area51.meta.stackexchange.com

Cannot access the Area51 Discussion Zone via HTTPS

Trying to access https://area51.meta.stackexchange.com/ gives an error.

Screenie: Error!

  • 1
    A51 codebase has trouble updating with rest of SE, news at 11. – Nathan Tuggy Mar 20 '17 at 10:03
  • area51.stackexchange.com is still in the todo list. – DavidPostill Mar 20 '17 at 10:29
  • 1
    This isn't done yet - it's in the list above as not done yet... – Nick Craver Mar 20 '17 at 12:20
  • There's a lot of code to move for this one - but it'll be moved to area51.meta.stackexchange.com as soon as time allows. – Nick Craver Apr 16 '17 at 16:49
  • 2
    @NickCraver Uhm, I just stumbled across another issue regarding area51 and SSL... Try this link – rahuldottech Jun 29 '17 at 20:43

?

When uploading an image in chat (SE), the link posted to chat is http instead of httpS.

the upload dialog from chat
the resulting link uses http instead of https

Tested on Opera and Firefox in private/incognito sessions, connecting to chat both through http and https.

Shouldn't be a difficult fix.

  • It's also worth noticing that the community bot did not convert Stack Imgur's HTTP images to HTTPS (while they can be converted just by adding the "s"). – Gallifreyan Jul 12 '17 at 7:26

Shorthand links in comments, like [su], still resolve to http://, not https://.


Receiving the https:// error in the Area51 proposal page for Qubes, those contain a script in it. Still the script cause an error, despite it being over https: https://edge.quantserve.com/quant.js

In plain text the error says:

Parts of this page are not secure (such as images).

The excerpt and wiki needs to be updated once TLS is supported (and the tag should probably be renamed from to , but that's a different discussion).

Main Tags on Meta Sites revert to “http”

If you type something like [tag:foo] or [meta-tag:bar] into a post, you get something that looks like and links to site.stackexchange.com/questions/tagged/foo or site.meta.stackexchange.com/questions/tagged/bar1, as appropriate.  Based on a sampling of about ten communities, if you go to the main (non-meta) site, using https, and use the tag2 Markdown, you will get a link to the appropriate https questions/tagged/tag URL.  As expected.

In the communities that I tested, if you go to the meta site, using https, and use the meta-tag Markdown, you will get a link to the appropriate https://site.meta.stackexchange.com/questions/questions/tagged/tag URL.  As expected.

In many of the communities that I tested, if you go to the meta site, using https, and use the tag Markdown, you will get a link to http://site.stackexchange.com/questions/tagged/tag.  This is wrong.

These communities get it right:

  • Meta Stack Exchange
  • (Meta) Super User
  • (Meta) Information Security

All other communities that I tested — including Stack Overflow — got it wrong.
___________
1 or meta.sitename.com/questions/tagged/bar, for those communities (Stack Overflow, Super User, Server Fault, Ask Ubuntu, etc.) not conforming to the site.stackexchange.com template.
2 non-meta sites don’t recognize the [meta-tag:tag] Markdown.

  • 1
    Surely that's correct for now? the communities that get it right are the only ones finished switching to HTTPS AFAIK... – Cai Mar 19 '17 at 10:19
  • @Cai: Well, I don’t know the full plan exactly, but (1) I got the impression that Meta Stack Exchange, Stack Overflow and Information Security were supposed to be done ahead of everything else, and (2) They’ve been working for over five years to make the whole site https-friendly.  Having an https page explicitly generate a link to an http page (within the site) seems like something they would have wanted to fix long ago. – Scott Mar 19 '17 at 18:54
  • no, not Stack Overflow... the only main sites that are currently https enabled are Super User and Security SE – m0sa Mar 20 '17 at 9:04

Just an observation:

In the Stack Exchange Privileges, some of the privilege page contains the other Stack Exchange post's link in it. Those links are still as http://, but when clicking on the links it will open as https://.

It is not cause any issue, but updating those http:// links also will be uniformity with the links.

Sample privilege page:

In the bottom of the Community Wiki page, there is the http:// link

Also see What are “Community Wiki” posts?

  • 2
    We'll be re-baking all links in the network to be https:// everywhere (to eliminate 301s for users). We'll do this after the move of all of Q&A, since we can just assume https:// across the board, do a rebake once, and simplify all logic involved. – Nick Craver Mar 15 '17 at 22:54
  • Why did you roll back the automatic edit? Why have useless redirect? – Shadow Wizard Aug 2 '17 at 14:44
  • @ShadowWizard See my comments in the Revision 4: In the actual privilege page the https url is not yet updated, so I changed back the http url in the post. The issue is not yet solved. – Arulkumar Aug 2 '17 at 14:45
  • I see. Well, still not sure we should actually quote the link as-is. It's clear enough what you request. – Shadow Wizard Aug 2 '17 at 14:46

As noted here on Area 51 Meta, OpenID login on Area 51 still goes through an insecure HTTP request (and breaks if that request is rewritten to use HTTPS, e.g. by HTTPS Everywhere).

I've reported the latter issue to the HTTPS Everywhere devs, and they've added an exclusion for the problematic URL for now. But that does nothing to fix the real underlying issue with the insecure login URL.

(Ps. I'm about 90% sure that the only thing needed to fix this is adding the missing s to the OpenID return URL parameter in the Area 51 codebase. Letting HTTPS Everywhere rewrite the URL to use HTTPS does work, in the sense of apparently reaching the correct OpenID authentication endpoint, but the auth code then detects the rewrite as an unexpected URL modification and aborts the login process.)

Will api.stackexchange.com continue to be available though HTTP?

  • 6
    The plan is to force all traffic over to https:// - but I am of course curious why you're asking... – Nick Craver Mar 14 '17 at 20:37
  • 5
    Actually mostly because of things like this. With forced HTTPS it may be trickier to use SE API without proper frameworks and libraries. One can type HTTP request in netcat, but not HTTPS request. – Vi. Mar 16 '17 at 12:07

We have also rebaked links inside the network (except comments) to point to the new domains and protocol.

I still see http:// links in Super User posts.

E.g. in my question, Advertisement suddenly appearing on top of almost every page, the original http:// links (e.g. the http://superuser.com/a/832009/213663) are still http://.

Unless I misinterpret the above statement.

  • 1
    superuser links were processed just now, including your example – m0sa Mar 20 '17 at 10:19

Apparent

HTTPS conversion seems to have cancelled newsletter subscriptions

So far this only affects MSE, but before rolling out changes to the rest of the network, I suggest investigating to either fix it or announce that people will need to re-subscribe to their newsletters. (Either's fine IMO; it's the silent drop we want to avoid.)

  • 1
    I'm digging into this now, hope to get all the data fixed up today. – Nick Craver Mar 20 '17 at 13:58

The total page views from the moderators dashboard in Meta StackOverflow in spanish does not show any data at all.

Links to comments (I didn't check for another stuff) in Stack Exchange Data Explorer should be fixed for persite metas. E.g. from meta.ru to ru.meta:

meta.ru

Tested in this query for ruSO.meta.

  • 1
    Proper bug report here – rene Oct 26 '17 at 16:03
  • @rene looks like that bug is fixed. In my case there is https already. – alexolut Oct 26 '17 at 16:14
  • On second thoughts this is better raised as a specific bug for sede – rene Oct 26 '17 at 16:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .