Hacker News new | comments | ask | show | jobs | submit login

Embedding via // without explicit SSL should probably be considered harmful or malicious as there is no reason to make such scripts available without SSL. Even if the end website is not using SSL users can still fetch your script securely.

The example snippet uses SRI [1], so there's no security issue with plain HTTP.

[1] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

It's not supported by IE.

IE doesn't support script type "module" anyway, so it'll ignore the script tag: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sc...

There’s no security gain from going to HTTPS if the site is served over HTTP, but there’s a small speed hit.

The communication between the user and example.com downloading the page referring to your script is secured by their SSL if they have it.

Separately to that, the communication between the user and your server when downloading your script is secured by your SSL. This can be secure even if example.com is not, so it should only be secure.

If the first html load isn't on SSL, and someone is able to intercept your traffic, they can change the embedded https url to be a non-https url anyway, so I can't even imagine the attack that is prevented by using https into something loaded over http.

Absolutely correct. But this is the website owner's problem and their consequences for not using SSL. You can't help or prevent this because it's not your server, it's not your fault they enabled insecure communication that can be exploited.

When you forgo SSL on your own server someone can also intercept your script in exactly the same way, they don't need to hack the website embedding your script. Now they are your consequences, your fault there's no SSL, and your problem may be affecting everyone who embedded your script insecurely.

No site should be served over plain HTTP in 2019. Browsers and search engines are actively discouraging/downranking websites that don't use TLS at this point.

None should be, but several are. Just the way that it is.

By the way, since .page is HSTS-preloaded, you may as well include https:// in the code snippet that includes the library. It'll avoid the http-to-https link rewriting internal redirect from happening when included from a non-secure site. It's a tiny performance improvement, but across millions of page views, it might add up.

If the browser sends a Referer header, the page the user is currently on will be sent over plaintext.

For exactly this reason browsers don’t send a Referer header when an HTTP request is made from an HTTPS page. (Nor for any kind of request made from a local file.)


You should NEVER load javascript over https on a page that was served over http.

It gives a false sense of security that doesn't exist.

Because the source page was served over http, the source page can be modified by an attacker, making the script be loaded under ssl makes you think its protected. But its not since an attacker could just modify the script tag to remove the https bit in transit then modify the script thats now being loaded over http.

In sort, forcing the script to use https gives you no gain when the page that includes it is served over http and it tricks you into thinking that javascript asset is secure.

Who does this affect? The attacker can always modify the page however they want anyways and the https for the js source would mean the js itself cannot be tampered with

Does it help much? No. Should you use it? Yes.

Who is being tricked? I don't suspect the user is checking the script tags to see if they are secure. At the very least, this might stop basic ISP tampering used to inject bandwidth warnings, etc.

The programmer that put the script tag in there.

Or just stop using HTTP like a normal person. Who still has pages served over anything hit HTTPS?

     Who still has pages served over anything hit HTTPS?
Someone who wants to explore our emerging financial liability as we grow increasingly compelled by law to actively protect data in transit (that's SSL), at rest, and in distribution.

     Penalties for violations can be huge, as much as 20 
     million euros or 4% of the company's annual turnover.

No browsers present that to users as a secure context, so nobody is being tricked.

More HTTPS == Better. If you can load this over HTTPS you should, no matter what circumstance. The browsers iconography will handle notifying people when the context is secure or not.

FYI, the entire .page TLD is HSTS-preloaded. So in HSTS-preload compliant browsers, this will be rewritten as an https URL prior to fetching it even if included on an http page. In Chrome, you can use web inspector to see the link being rewritten using a 307 'Internal Redirect' prior to sending the request to instant.page.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact