Comments on: More HTTPS Troubles

By: SSLStrip pone las fallas de SSL al descubierto | Geekotic

SSLStrip pone las fallas de SSL al descubierto | Geekotic — Wed, 17 Jun 2009 22:12:24 +0000

[…] Hackademix.net, sitio del autor de la extensión NoScript para Firefox, donde explica además como usarla para protegerse de estos exploits. […]

By: AndrewM

AndrewM — Sat, 28 Mar 2009 03:19:09 +0000

An update: Bug 479336 (https://bugzilla.mozilla.org/show_bug.cgi?id=479336) added some more characters (including the one used in the example above) to the blacklisted IDN characters in network.IDN.blacklist_chars (full list: http://kb.mozillazine.org/Network.IDN.blacklist_chars). So a fix for this should be in Firefox 3.0.9.

I was also impressed to see that IE8 and Chrome 1.0.154.53 are already protected against this.

Also, the link to Password Safe in comment 24 needs an extra ’s’ in it, so it’s:

http://www.schneier.com/passsafe.html

By: Aerik

Aerik — Tue, 03 Mar 2009 20:13:49 +0000

Good suggestion Paul.

If you don’t need a www in a domain then eliminate it.

I suggest incorporating this into your use of BlockSite.

Know what else I do on sensitive sites? I put network.http.redirection-limit to 0, or at most 1. I think the default value for this preference should be 1 anyways. That’s generally all that’s ever necessary on sites that use a redirect to serve content of some kind, or on forums that redirect you to your post in the thread after you post a reply. The current default, 20, is ridiculous.

Finally, it’s a good idea to open noscript’s options and set "forbid active web content unless it comes from a secure (HTTPS) connection:" to "always" when on a sensitive site.

And set noscript.forbidXHR to 3 except when it absolutely must be lowered.

Then do your sensitive stuff in private browsing mode.

In fact you should probably create an entire firefox profile just for doing this sort of stuff, with all these suggestions employed.

By: CapnCanuck

CapnCanuck — Thu, 26 Feb 2009 17:04:37 +0000

@ Paul: Thats a great idea, there shouldnt be any reason for secure sites to only operate on the HTTPS protocol. But from my understanding, https is an extension of http, so therefore you cant have https without http..i think

By: Paul

Paul — Mon, 23 Feb 2009 20:48:16 +0000

It seems to be that anywhere offering a secure site should _only_ offer https services.
Users won’t be so exposed to this if they only have https urls in their bookmarks/history/autocomplete. The window of exposure is reduced to the first time they type in the addresses.
It may not be feasible to drop http completely for sites used by the general public (but may be in many cases for private applications).
In that case the http site could do nothing but issue a redirect permanent to the https site. That would make bookmarks secure and possibly (depending on browser behaviour) history/autocomplete safer.

I suppose some sites will be navigated to via weblinks rather than accessed directly as above so it’s not a total solution, but that is probably true of the problem in general, it’s one you can minimise your exposure too rather than magically fix for all situations.

By: SSLStrip pone las fallas de SSL al descubierto «

SSLStrip pone las fallas de SSL al descubierto « — Mon, 23 Feb 2009 15:37:42 +0000

[…] REFERENCIA: hackademix.net […]

By: Tom T.

Tom T. — Mon, 23 Feb 2009 13:14:16 +0000

Loophole: if you are lazy and type wachovia.com, the suggested changes will not work. Normally, your browser would add the www prefix when the shortened URL doesn’t work; however, wachovia and one of my local credit unions are configured so that typing without the www still takes you to the same (unencrypted) login page. Solution: add to the “Force HTTPS” list the following, without wildcards: http://wachovia.com or any other site that shows this behavior when www. is not typed. Or don’t be lazy, and type the www. Or bookmark it. Or even better, put the correct URL in Password Safe, free and open-source from Bruce Schneier www.schneier.com/passafe.html.

By: Steven Andrés

Steven Andrés — Mon, 23 Feb 2009 01:00:41 +0000

@NM: I think the Firefox feature you’re talking about is one of my favorites and one that I really wish was a default:

http://kb.mozillazine.org/Browser.identity.ssl_domain_display

I have mine set to level "2" which shows the entire CN of the certificate in the address bar in blue. It’s a really big attention-getter and looks almost as in-your-face as the Extended Validation green-bar UI. I try to flip this setting on all my friends/family/users Firefox installs so they have a strong visual feedback of non-EV certificates and hopefully would be able to catch on to an attack.

By: Aerik

Aerik — Sat, 21 Feb 2009 13:32:07 +0000

I do think it’s smart strategy, because I was toying with blocksite in whitelist mode when I discovered something very interesting.

I use the extension "twittytunes" to post to twitter. A very simple interface. What’s interesting is that in whitelist mode, blocksite will cut off this extension’s connectivity to twitter if I do not whitelist http://twitter.com/* . Even ReqestPolicy isn’t that powerful.

This means (I think): blocksite in whitelist mover overcomes Bug 431782 "HTTP redirects can bypass content policies."

By: Giorgio

Giorgio — Sat, 21 Feb 2009 11:57:28 +0000

@Aerik:
sound like a smart strategy.
It will be made much less painful by ABE.