HTTPS Mixed content

[Giorgio Maone]

Just another query. Can I just confirm:

This code means live.com and twitter.com are exempted from the rule (presumably the "comma" separates it out):

Code: Select all

Site ^http://
Accept from .live.com, .twitter.com
Deny from ^https://

You don't need the comma, just use spaces.

This code means nothing is exempt from the rule (I notice I have to put the "full stop" to ensure the code works):

Code: Select all

Site ^http://
Accept from .
Deny from ^https://

If you don't want to exempt anything just omit the "Accept" clause:

Code: Select all

Site http:
Deny from https:

[EDIT]
per al9_x's suggestion, denying just INClusions has the same security properties but is more usable:

Code: Select all

Site http:
Deny INC from https:

[ssj100]

What's the difference between using ABE and using this option here to block mixed content?:


One big difference is that I find it harder to make exceptions. For example, I can't seem to log into a Hotmail account with the HTTPS method above even if I exempt live.com.

[Giorgio Maone]

What's the difference between using ABE and using this option here to block mixed content?:

The "Forbid active content unless it comes from HTTPS connections" option has nothing to do with mixed content (unless we mean mixed at the global, browser level, rather than at the page level as it is usually referred).
It should always be kept to its default ("Never") unless you know what you're doing, because it completely disables JavaScript and plugins on websites which are not served through HTTPS (i.e., the vast majority), disabling also the related "Allow" menu items to prevent accidental enablement.

This makes sense only if you are in a hostile network (typically behind a proxy potentially controlled by an attacker, e.g. TOR) but you don't want to give up active content on sites you trust, as long as they cannot be spoofed (i.e. they're using SSL).
That's why its most sensible value, if you're using the TOR button, is "When using a a proxy", which will automatically switch on and off depending on the proxied state of the connection.
In all the other cases (i.e. for "normal" browsing), this option is better to be kept "Never".

[ssj100]

Thanks for the information.

By the way, it's not just Hotmail that has a problem when you add that code. Yahoo Mail also has the same problem - you need to exempt ".yahoo.com" to be able to log in.

From what you're saying, people shouldn't be using Hotmail and Yahoo? Last time I checked, the vast majority of people who have web-mail either use Hotmail or Yahoo? Do you have a Hotmail or Yahoo account? Can you check it out to see why they both require http content to be loaded into their https login process?

[Giorgio Maone]

By the way, it's not just Hotmail that has a problem when you add that code. Yahoo Mail also has the same problem - you need to exempt ".yahoo.com" to be able to log in.

Can I see a sample of the [ABE] messages you should get in Tools|Error Console when this happens?

[ssj100]

I don't get any errors in the Error Console. I've sent you a PM of what I do see.

[Giorgio Maone]

I don't get any errors in the Error Console. I've sent you a PM of what I do see.

Does the problem persist if you add .yahoo.com and .live.com to your "Forced HTTPS" list?
If it does, or the site stops working, then it's time to change your email provider, or at least not to use it for sensitive information (e.g. password reminders, financial statements and so on).
GMail works fine from this standpoint.

[ssj100]

I don't get any errors in the Error Console. I've sent you a PM of what I do see.

Does the problem persist if you add .yahoo.com and .live.com to your "Forced HTTPS" list?
If it does, or the site stops working, then it's time to change your email provider, or at least not to use it for sensitive information (e.g. password reminders, financial statements and so on).
GMail works fine from this standpoint.

Well, I get the following message in Firefox if I add those to the "Forced HTTPS" list (this is for Hotmail):

This Connection is Untrusted

You have asked Firefox to connect
securely to bl149w.blu149.mail.live.com, but we can't confirm that your connection is secure.

[Giorgio Maone]

Well, I get the following message in Firefox if I add those to the "Forced HTTPS" list (this is for Hotmail):

This Connection is Untrusted

You have asked Firefox to connect
securely to bl149w.blu149.mail.live.com, but we can't confirm that your connection is secure.

That's almost fine.
This error page should give you a chance to examine the certificate. You'll probably find that it belongs to live.com or mail.live.com.
If it does, you can safely add it to your exceptions list, even though the strict domain check performed by Firefox correctly fails.
If it doesn't (i.e. the certificate belongs to a CDN provider, such as AKAMAI), you're probably out of luck and you'd better give up with this webmail service.

[al_9x]

Well if you use Hotmail, you'll need to add "live.com" into the exceptions list of your code, otherwise you can't login!

This mean the site is buggy beyond any hope (because it forces unencrypted HTTP on some exchanges, for inexplicable reasons), and you should stop using it by principle.

Is there are reason you are recommending "Deny from https:" rather than "Deny INC from https:"?

"Deny from https:" will block links and redirects replacing the root document and JS popups. I am not sure that's desired. Incidentally, I noticed that with scripting off, window.open('http://...') is not blocked by "Deny from https:" That's a bug?

Another related issue, "Deny INC from https:" correctly blocks user initiated iframe navigations to http: but does not show alerts. Do you think perhaps an exception should be made here? Whereas it makes sense to hide INC block alerts for autoloading resources, but for a document replacement, you probably do want to see an alert, especially when the navigation is user initiated (don't know if it's possible to detect that)

[Giorgio Maone]

Is there are reason you are recommending "Deny from https:" rather than "Deny INC from https:"?

Lazyness.

"Deny from https:" will block links and redirects replacing the root document and JS popups. I am not sure that's desired.

For most uses of this rule is not a big problem, however INC is more usable, indeed. I'm gonna edit the original rule.

Incidentally, I noticed that with scripting off, window.open('http://...') is not blocked by "Deny from https:" That's a bug?

Do you mean "automatically fixed" JavaScript URLs? I'm gonna check.

Another related issue, "Deny INC from https:" correctly blocks user initiated iframe navigations to http: but does not show alerts. Do you think perhaps an exception should be made here?

It was an idea I was toying some time ago, adding some modifiers to ABE actions, e.g. "?" to make it interactive (i.e. show the notification even if the match is a subrequest and include a button to bypass) and "!" to force the rule quietly even if a notification would have been otherwise issued:

Code: Select all

# WARNING: THIS RULE IS PROTOTYPAL AND DOESN'T WORK IN NOSCRIPT 2.0.x YET
Site http:
Deny? SUBDOC from https:
Deny INC from https:

# WARNING: THIS RULE IS PROTOTYPAL AND DOESN'T WORK IN NOSCRIPT 2.0.x YET
Site malicious.com
Deny!

[ssj100]

Thanks, by changing it to "Deny INC from https:", I'm able to log into Hotmail and Yahoo without the need to add exceptions.

Another related issue, "Deny INC from https:" correctly blocks user initiated iframe navigations to http: but does not show alerts. Do you think perhaps an exception should be made here? Whereas it makes sense to hide INC block alerts for autoloading resources, but for a document replacement, you probably do want to see an alert, especially when the navigation is user initiated (don't know if it's possible to detect that)

Can someone please give an example of this issue? I'm struggling to understand it. What exactly is "INC"? And what exactly is the "alert" we would want to see? Thanks!

[Giorgio Maone]

Can someone please give an example of this issue? I'm struggling to understand it. What exactly is "INC"? And what exactly is the "alert" we would want to see? Thanks!

INC stands for "INClusions", i.e. anything that gets included by a certain web page, i.e. that is not a top-level document, e.g. iframes, scripts, stylesheets, XHR and so on.
Check http://noscript.net/abe for more info.

What al9_x was pointing out is that currently ABE's yellow notification bar is issued only for top-level document loads, because they're the ones which have more impact on user and therefore a notification is desirable.

My idea was about giving more flexibility to rules in deciding whether they should be applied silently or should issue a notification (possibly with a bypass option) when matched.

[ssj100]

What al9_x was pointing out is that currently ABE's yellow notification bar is issued only for top-level document loads, because they're the ones which have more impact on user and therefore a notification is desirable.

I see, so what you're saying is that a web-site could potentially be broken and you don't realise it (because NoScript ABE didn't issue a notification?).

Can someone give me an example of this on a web-site? Thanks.

[Giorgio Maone]

Can someone give me an example of this on a web-site? Thanks.

Try to use https://twitter.com with the rule above.