465

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.

Improve this question
62
  • 11
    For 11. chat, how about you migrate chat.so to chat.se and have a problem less?
    – Braiam
    Commented Mar 8, 2017 at 14:51
  • 21
    @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
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 at 15:00
  • 9
    Do you want bug reports as answers to this, separate questions tagged bug and ssl, or something else?
    – ale
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 at 15:25
  • 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
    Commented Mar 8, 2017 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?
    – user311528
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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
    Commented Mar 9, 2017 at 1:30
  • 1
    Answer: it's SOUP.
    – Monica Cellio
    Commented Mar 9, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 11, 2017 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
    Commented Mar 30, 2017 at 1:50
  • 1
    @Nick what about stackpromos.com?
    – Shadow Wizard
    Commented Aug 6, 2017 at 10:45

42 Answers 42

Reset to default
1
2
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:

Improve this answer
19
  • 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.
    – user
    Commented Mar 8, 2017 at 17:42
  • 2
    Apparently, **www.**meta.stackoverflow.com doesn't load for me, but removing the www. makes it load just fine
    – user41805
    Commented Mar 8, 2017 at 17:59
  • @MichaelKjörling FWIW means?
    – Suraj Jain
    Commented Mar 8, 2017 at 18:46
  • 1
    @SurajJain FWIW = For Whatever It's Worth.
    – user
    Commented Mar 8, 2017 at 18:52
  • 16
    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
    Commented Mar 8, 2017 at 19:24
  • @NickCraver what di you mean by none of domain are on www?
    – Suraj Jain
    Commented Mar 8, 2017 at 21:52
  • 2
    @NickCraver Actually as you can see in image , it give the issue when visited on non www.
    – Suraj Jain
    Commented Mar 8, 2017 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
    Commented Mar 9, 2017 at 0:41
  • @NickCraver What was really happening ? I am not seeing it anymore , What did you do ?
    – Suraj Jain
    Commented Mar 9, 2017 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
    Commented Mar 9, 2017 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
    Commented Mar 9, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 11, 2017 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
    Commented Mar 11, 2017 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
    Commented Mar 16, 2017 at 0:28
23

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.

Improve this answer
10
  • 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?
    – Cave Johnson
    Commented Mar 14, 2017 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
    Commented Mar 14, 2017 at 20:01
  • 8
    I will be submitting PRs to the extension as we make network changes.
    – Nick Craver
    Commented Mar 14, 2017 at 20:36
  • 2
    I've opened a tracking issue.
    – Bardi Harborow
    Commented Mar 15, 2017 at 6:11
  • 4
    A PR has been submitted here: github.com/EFForg/https-everywhere/pull/9110
    – Nick Craver
    Commented Mar 16, 2017 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
    Commented Mar 17, 2017 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
    Commented Mar 18, 2017 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
    Commented Mar 18, 2017 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
    Commented Mar 21, 2017 at 22:22
  • @NickCraver Pull Request is merged, It is completed. shall we mark it as status-completed.
    – Suraj Jain
    Commented May 28, 2018 at 16:50
21

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.

Improve this answer
9
  • Which page are you referring to? Area 51 isn't enabled for HTTPS yet, as indicated in step 10 above :)
    – Nick Craver
    Commented Mar 8, 2017 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...
    – Mithical
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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://.
    – Mithical
    Commented Mar 8, 2017 at 19:56
  • @NickCraver I edited to clarify.
    – Mithical
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 at 20:14
  • bolded the https and http, looks more readable now. is it ok ?
    – Suraj Jain
    Commented Mar 22, 2017 at 2:46
  • @NickCraver How about correcting links in posts by community user?
    – Pandya
    Commented Mar 25, 2017 at 6:13
19

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.

Improve this answer
9
  • Related ?
    – Arulkumar
    Commented Mar 9, 2017 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
    Commented Mar 9, 2017 at 14:45
  • 1
    @NickCraver share link for current question is not parsed in preview.
    – αλεχολυτ
    Commented Mar 9, 2017 at 15:21
  • @Arulkumar possibly a duplicate.
    – αλεχολυτ
    Commented Mar 9, 2017 at 15:42
  • 6
    +1 for the freehand circles.
    – DaveTheMinion
    Commented Mar 10, 2017 at 3:20
  • @alexolut Ah - I gotcha on the actual issue, noted for fixing, will try and do so first thing Monday.
    – Nick Craver
    Commented Mar 10, 2017 at 21:52
  • Eh, it was bugging me. A fix is rolling to production now, thanks for the info!
    – Nick Craver
    Commented Mar 10, 2017 at 22:30
  • 1
    @NickCraver the problem of HTTPS links not getting titles is still happening, though
    – muru
    Commented Mar 11, 2017 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
    Commented Mar 14, 2017 at 20:33
12

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.

Improve this answer
3
  • 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
    Commented Mar 16, 2017 at 19:23
  • 2
    Manually removing and re-adding it will also fix the issue.
    – SEJPM
    Commented Mar 16, 2017 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
    Commented Mar 30, 2017 at 3:27
12

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

Improve this answer
10
  • 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
    Commented Mar 13, 2017 at 14:09
  • 3
    You should use protocol-inferred urls: //cdnjs.cloudflare.com/ajax/libs/jquery/3.1.1/jquery.js
    – user338745
    Commented Mar 13, 2017 at 21:02
  • 6
    @programmer5000 it's really better to use https://, which is HTTP/2 and faster in most cases there.
    – Nick Craver
    Commented Mar 14, 2017 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
    Commented Mar 14, 2017 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
    Commented Mar 14, 2017 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ı
    Commented Mar 14, 2017 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
    Commented Mar 14, 2017 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
    Commented Mar 16, 2017 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.
    – user338745
    Commented Mar 18, 2017 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
    Commented Mar 18, 2017 at 13:58
11

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 https://i.sstatic.net/aXihi.gif, receiving the warning due to this.

Improve this answer
5
  • 3
    Noted - I've fixed this one but we'll have to address the help center globally - thanks!
    – Nick Craver
    Commented Mar 9, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 10, 2017 at 21:51
  • 1
    @vcsjones These should be resolve now - are you seeing any more?
    – Nick Craver
    Commented Mar 13, 2017 at 12:36
  • @NickCraver did some clicking around and looks good so far.
    – vcsjones
    Commented Mar 13, 2017 at 13:54
11

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.

Improve this answer
2
  • this is fixed now, edits on posts by community are excluded from queue the criteria
    – m0sa
    Commented Mar 17, 2017 at 10:27
  • 4
    What about anonymous suggested edits?
    – Double AA
    Commented Mar 17, 2017 at 11:20
10

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.

Improve this answer
9

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.

Improve this answer
8

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 ?

Improve this answer
3
  • Strangely Area 51 discuss http://area51.meta.stackexchange.com is automatically redirect to https://area51.meta.stackexchange.com, but not the Area 51 main site.
    – Arulkumar
    Commented Aug 9, 2017 at 6:19
  • @Arulkumar That's because A51 Meta uses the *.meta.stackexchange.com wildcard rule, so it's automatically redirected.
    – iBug says Reinstate Monica
    Commented Mar 6, 2018 at 9:59
  • 1
    @RandomPerson thanks, looks like they've fixed it regardless of Nick Craver's comment (now deleted). In the future, feel free to edit it yourself (the [status-declined] was added by a Meta regular, apparently based on Nick's comment, which is OK in my book).
    – Glorfindel Mod
    Commented Feb 20, 2022 at 18:54
7

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

enter image description here

Improve this answer
1
  • Yep - we haven't done this yet - it'll come later in the list #10
    – Nick Craver
    Commented Mar 13, 2017 at 12:38
7

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

Improve this answer
8
  • Got it, will fix Monday - thanks!
    – Nick Craver
    Commented Mar 12, 2017 at 0:35
  • This will be fixed as cache expires over the next hour.
    – Nick Craver
    Commented Mar 13, 2017 at 12:36
  • @NickCraver still not working for me.
    – αλεχολυτ
    Commented Mar 20, 2017 at 3:11
  • @Nick still broken in the Edit Profile preferences section: i.sstatic.net/o2UmC.png can you please fix it there as well?
    – Shadow Wizard
    Commented Mar 20, 2017 at 9:00
  • @ShadowWizard 2 months gone and problem still exists despite of status-completed
    – αλεχολυτ
    Commented May 27, 2017 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
    Commented May 27, 2017 at 13:44
  • @ShadowWizard different problem with same behavior?
    – αλεχολυτ
    Commented May 27, 2017 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
    Commented May 27, 2017 at 13:47
7

?

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.

Improve this answer
1
  • 1
    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
    Commented Jul 12, 2017 at 7:26
7

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.

Improve this answer
6

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

Improve this answer
4
  • 9
    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
    Commented Mar 14, 2017 at 20:42
  • 1
    OTOH SSL Labs reports A.
    – Martin Schröder
    Commented Mar 14, 2017 at 21:16
  • [status-deferred] then?
    – Robotnik
    Commented Mar 16, 2017 at 0:21
  • I get D- for meta.stackexcange.com, and F for StackOverflow??
    – stevefestl
    Commented May 1, 2017 at 7:53
6

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

Improve this answer
5
  • 2
    A51 codebase has trouble updating with rest of SE, news at 11.
    – Nathan Tuggy
    Commented Mar 20, 2017 at 10:03
  • area51.stackexchange.com is still in the todo list.
    – DavidPostill
    Commented Mar 20, 2017 at 10:29
  • 1
    This isn't done yet - it's in the list above as not done yet...
    – Nick Craver
    Commented Mar 20, 2017 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
    Commented Apr 16, 2017 at 16:49
  • 2
    @NickCraver Uhm, I just stumbled across another issue regarding area51 and SSL... Try this link
    – undo
    Commented Jun 29, 2017 at 20:43
6

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

Improve this answer
1
6

In the Moderators tab in the Users page in a graduated site, for example: https://stackoverflow.com/users?tab=moderators, there is an "elected [year]" link below each user. This link is still in HTTP.

Improve this answer
4
  • 1
    Is it a problem? There are default redirects to https. It only causes an extra 302 repsonse that could have been prevented. Unless I miss something
    – rene Mod
    Commented Jan 1, 2020 at 19:14
  • 3
    This post is over 2 years old now and no one is really paying attention to it. New bugs are better served by creatinga new question.
    – animuson StaffMod
    Commented Jan 1, 2020 at 19:33
  • 1
    @animuson Well, it's a too small problem. Maybe not worth it.
    – user23013
    Commented Jan 1, 2020 at 19:36
  • 4
    @animuson Here you go: meta.stackexchange.com/q/376439
    – Random Person
    Commented Feb 20, 2022 at 18:45
6

Have just updated thousands of posts on SO, MSO, and MSE, changing http:// to https:// for all chat domains, the blog, data and stackexchange.com

As continuance of the question I wrote earlier today (HTTP -> HTTPS script didn't change everything):

Can we make the community user run a script to convert all links to chat to make use of the HTTPS protocol as well?

On MSE there are 681 occurrences of the HTTP version of the link to chat. credit to Glorfindel

MSO has 459 occurrences and SO has 735 of them.

These are too many instances to handle manually, and also it would disrupt the front-pages disproportionately when done manually.

EDIT: It appears there are other links that haven't been converted either, as pointed out by Stormblessed. These are data.SE and http://stackexchange.com, with the latter having 1416 occurrences on MSE.

Improve this answer
0
5

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

Improve this answer
3
  • 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
    Commented Mar 13, 2017 at 14:10
  • 1
    Can you still reproduce this bug?
    – SEJPM
    Commented Mar 14, 2017 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
    Commented Mar 14, 2017 at 21:46
5

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).

Improve this answer
1
5

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.

Improve this answer
3
  • 1
    Surely that's correct for now? the communities that get it right are the only ones finished switching to HTTPS AFAIK...
    – Cai
    Commented Mar 19, 2017 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 - Слава Україні
    Commented Mar 19, 2017 at 18:54
  • no, not Stack Overflow... the only main sites that are currently https enabled are Super User and Security SE
    – m0sa
    Commented Mar 20, 2017 at 9:04
5

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.

Improve this answer
2
  • 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
    Commented Mar 20, 2017 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
    Commented Mar 20, 2017 at 21:12
5

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.)

Improve this answer
5

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?

Improve this answer
6
  • 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
    Commented Mar 15, 2017 at 22:54
  • Why did you roll back the automatic edit? Why have useless redirect?
    – Shadow Wizard
    Commented Aug 2, 2017 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
    Commented Aug 2, 2017 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
    Commented Aug 2, 2017 at 14:46
  • @ShadowTheKidWizard This is now status-completed right?
    – Random Person
    Commented Sep 12, 2022 at 16:37
  • 1
    @RandomPerson yes, Nick did it years ago, and probably forgot about this specific post. :)
    – Shadow Wizard
    Commented Sep 12, 2022 at 16:45
4

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).

Improve this answer
3
4

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

Improve this answer
2
  • 6
    The plan is to force all traffic over to https:// - but I am of course curious why you're asking...
    – Nick Craver
    Commented Mar 14, 2017 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.
    Commented Mar 16, 2017 at 12:07
4

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.)

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

With the deployment of https I see a huge drop in StackOverflow referral traffic in the analytics of our own site. Many of the links in SO that point to our site were written when we had no https equivalents (we've moved to https a while ago, though). Since by default referral information is not passed from https to http sites, the information now gets lost and I see a decrease by a factor of about 20 in the referrals. That's not really a big problem, because people are probably still clicking on the links and are being successfully directed to our site, however they do not appear in analytics anymore and StackOverflow suddenly dropped dramatically in the referral ranking, which is sad from the analytics point of view.

Would it be possible to employ the "unsafe-url-referrer-policy" on SO sites? That would reenable referrers for links that are still targetting http sites.

Improve this answer
1
  • 2
    Think it's worth of a new feature request.
    – Shadow Wizard
    Commented Jun 28, 2017 at 14:41
1
2

You must log in to answer this question.

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