2
$\begingroup$

I have been wondering about people writing things like $H(X) = \sum -p_i\ log_2 p_i$ all the time, until I figured out – with the help of a more web2.0-affine friend – that this is Teχ (I'm a nroff guy personally so I didn't recognise it) and rendered by something called MathJax.

Unfortunately, even after enabling mathjax.org in RequestPolicy, this does not work – FireBug shows how:

Laden von gemischten aktiven Inhalten "http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML" wurde blockiert.

(Sorry for the German – I normally use Lynx and am a mere user here, and have no idea how to get it to use the English I normally also prefer in IT.) Translation: Loading of mixed active contents "$url" was blocked.

The cause here is obvious: SE (URI exemplary) uses https, of course – since I am logged in – but requests the ECMAscript from an http-only URI. (I did try accessing it via https but only got a response from a server with a certificate for *.akamaihd.net, *.akamaihd-staging.net, a248.e.akamai.net, so this wouldn't work even if SE were to use an https URI.)

The https-everywhere plugin sends the stackexchange session to https, which is the right thing to do since I’m logged in.

So… what to do?

PS: meta.crypto.stackexchange.com is also not covered by the certificate… but I permitted that, for now.

$\endgroup$
10
  • $\begingroup$ Sorry for sounding stupid, but where is the bug hitting you then? Is this down to a more strict lock-downs on your browser? I've not had this issue personally $\endgroup$
    – Cryptographeur
    Commented Jan 7, 2014 at 10:45
  • $\begingroup$ This is because an https site may not load content from an http site. This is actually default in, for example, recent Firefox® versions, and has been a warning even in MSIE 5 back in those days. More info $\endgroup$
    – mirabilos
    Commented Jan 7, 2014 at 13:45
  • $\begingroup$ I'm on my work system, but it doesn't appear to be using an HTTPS connection at all? Are you forcing it with https-everywhere, or am I the one with the issue here? $\endgroup$
    – Cryptographeur
    Commented Jan 7, 2014 at 13:48
  • $\begingroup$ Hm indeed, xul-ext-https-everywhere is installed on this system. But it’s only sensible to use https when I’m logged in on any system, so… $\endgroup$
    – mirabilos
    Commented Jan 7, 2014 at 13:55
  • 2
    $\begingroup$ Well if you're forcing HTTPS on a site that doesn't want to use HTTPS then it doesn't really feel like a bug, more a feature request for https usage. You're forcing HTTPS on the site, and it nearly supports it, rather than it offering https and not implementing it correctly $\endgroup$
    – Cryptographeur
    Commented Jan 7, 2014 at 13:58
  • $\begingroup$ AIUI, “https everywhere” have a list of sites (they even messaged me-as-a-site-owner and told me about the mixed content policy change), so the “doesn’t want to use https” doesn’t exactly apply. But anyway, maybe this can still be fixed? I will, however, amend the question. $\endgroup$
    – mirabilos
    Commented Jan 7, 2014 at 14:39
  • 2
    $\begingroup$ FWIW, the MathJax CDN can be accessed via https, see the documentation at docs.mathjax.org/en/latest/start.html#secure-access-to-the-cdn $\endgroup$
    – Peter Krautzberger
    Commented Jan 7, 2014 at 22:56
  • $\begingroup$ @PeterKrautzberger wonderful, thanks! Now we “only” need to get the attention of some SE developer to integrate this. How? $\endgroup$
    – mirabilos
    Commented Jan 8, 2014 at 10:37
  • 1
    $\begingroup$ Related bug report on MSO: SSL breaks TeX rendering $\endgroup$
    – Ilmari Karonen
    Commented Jan 13, 2014 at 12:00
  • 1
    $\begingroup$ The MathJax CDN now provides SSL acccess directly. Please don't use the Rackspace URL anymore it will be retired soon -- see mathjax.org/upcoming-changes-to-the-cdn Since this page has a very good Google rank for "MathJax, SSL", could one of the mods incorporate this information? Thanks! $\endgroup$
    – Peter Krautzberger
    Commented Jul 14, 2014 at 15:11

4 Answers 4

Reset to default
5
$\begingroup$

The https-everywhere plugin sends the stackexchange session to https, which is the right thing to do since I’m logged in.

That is... if it's one of the StackExchange sites that actually support HTTPS already. As far as I know, https://crypto.stackexchange.com/ currently does not yet have (full) HTTPS support.

So actually, it's not the right thing to do in this case. As you've noticed: as soon as you force sites into using HTTPS (with plugins like HTTPSeverywhere) stuff can and will go wrong, resulting in the kind of error(s) you're reporting.

Technical details from the trenches:

From what I was able to learn via various sources, StackExchange has invested a truckload of time and effort making all of StackExchange use HTTPS... but they're not there yet.

An interesting, related read might be "Stackoverflow.com: the road to SSL" by Nick Craver, posted on Apr 23, 2013 at his site.

When I first noticed the missing (better: incomplete) HTTPS support myself a few months ago, it was his blog-post that gave me a heads-up on the technical side as well as the issues, problems, and pitfalls involved in a StackExchange scenario. I'm sure it will be able to explain some things to you too.

Solution until full HTTPS support is established:

Create an exception, so the plugin/addon doesn't force SE sites into HTTPS until they actually support it.

$\endgroup$
5
  • $\begingroup$ Hmm, too bad. (Also thanks to @Gilles for the details in the other answer.) Do you know offhand how to do the exception, and whether login details at least will still stay secure that way? $\endgroup$
    – mirabilos
    Commented Jan 7, 2014 at 19:09
  • 1
    $\begingroup$ @mirabilos An MITM can grab your cookie and do everything they want with your account, including find out your private information (full name, email address, OpenID). If you're using SE's OpenID provider, your password is sent over HTTPS and cannot be recovered. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Jan 7, 2014 at 20:11
  • $\begingroup$ OK. Forcing SE to crypto.stackexchange.com/questions/12505/… after disabling the “partial” rule for SE in https-everywhere makes the graphics show up, so I will accept this as answer, although, what @Gilles said doesn't make me a happy camper, not at all… especially after Peter said MathJax CDN is available via https… $\endgroup$
    – mirabilos
    Commented Jan 8, 2014 at 21:07
  • $\begingroup$ "So actually, it's not the right thing to do in this case...." - I agree the wrong thing is being done somewhere, but... maybe the wrong thing is Stack Exchange not providing HTTPS. Consider the bigger security engineering picture, where users are taught the simple rule is "use https". The "use https" rule is easy teach to all users, like the housewife in America or the dissident student in Iran. Then, all the one off's, like Stack Exchange, become a problem for the average user and user education. $\endgroup$
    – user10496
    Commented Feb 17, 2018 at 3:53
  • 1
    $\begingroup$ @jww Yeah, well… this answer was posted 2014. Things somewhat changed since then and SE seems to meanwhile embrace https a bit more. ;) $\endgroup$
    – e-sushi Mod
    Commented Feb 17, 2018 at 18:29
4
$\begingroup$

When accessing pages that use MathJax (example: Subexponential algorithms for DLP in ℤs×ℤt) 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 alternative, you can use the following unmapped address:

https://c328740.ssl.cf1.rackcdn.com/mathjax/latest/MathJax.js

While not as appealing as cdn.mathjax.org, this address is stable and safe to use. For more information, see our documentation.

So everyone should now be able to enjoy the beauty of quality mathematics notation whichever protocol they prefer.

$\endgroup$
1
  • $\begingroup$ Note that the rackcdn.com URL is no longer supported; instead, the standard cdn.mathjax.org URL now works over HTTPS too. $\endgroup$
    – Ilmari Karonen
    Commented Jun 23, 2015 at 12:10
3
$\begingroup$

Unfortunately, Stack Exchange doesn't officialy support HTTPS yet. It mostly works on the main site, but several things are not supported, including MathJax.

At the moment HTTPS Everywhere should only apply to SE sites without MathJax.

$\endgroup$
2
  • $\begingroup$ Hm, is there a roadmap for full https support? This is something that, in my eyes, is essential – especially nowadays. $\endgroup$
    – mirabilos
    Commented Jan 7, 2014 at 19:10
  • $\begingroup$ @mirabilos SE very rarely announces roadmaps publicly, and they haven't given any dates for this that I know of. $\endgroup$
    – Gilles 'SO- stop being evil'
    Commented Jan 7, 2014 at 20:07
3
$\begingroup$

While waiting for the devs to fix this, I managed to come up with a user script workaround (for Firefox and Chrome users, at least). I've rolled it up with a bunch of other minor fixes (like MathJax not loading in 10k tools) into something I'm calling the Stack Overflow Unofficial Patch. Please feel welcome to give it a try!

The actual code that implements the workaround looks like this:

if ( 'https:' == location.protocol && 'undefined' === typeof(MathJax) ) {
    var mjs = $('script[src^="http://cdn.mathjax.org/"]').remove();
		if ( mjs.length > 0 ) $.ajax( {
        dataType: "script", cache: true,
        url: mjs[0].src.replace('http://cdn.mathjax.org', 'https://c328740.ssl.cf1.rackcdn.com')
    } );
}

Basically, it detects if MathJax failed to load normally, and if so, reloads it over HTTPS. There's a bunch of tricky issues that this code needs to deal with, like the fact that MathJax tries to be clever and find its own base URL by searching the DOM for script tags; if the original script tag isn't removed, MathJax will thus try to load its submodules over HTTP and fail. All in all, though, it seems to work pretty smoothly.

$\endgroup$
1
  • $\begingroup$ Ps. This fix is no longer needed, and has been removed from SOUP. Indeed, in the form given above, it wouldn't even work any more; you'd need url: mjs[0].src.replace('http:', 'https:') instead. $\endgroup$
    – Ilmari Karonen
    Commented Jun 23, 2015 at 12:26

You must log in to answer this question.

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