Weekly Edition
Return to the Security page
| |||||||||||||
|
| |||||||||||||
https-everywhere from the EFF
The Electronic Frontier Foundation has released a beta version of
https-everywhere, a Firefox extension which causes the browser to use
SSL whenever possible. "Many sites on the web offer some limited
support for encryption over HTTPS, but make it difficult to use. For
instance, they may default to unencrypted HTTP, or fill encrypted pages
with links that go back to the unencrypted site. The HTTPS Everywhere
extension fixes these problems by rewriting all requests to these sites to
HTTPS."
(Log in to post comments)
https-everywhere from the EFF Posted Jun 18, 2010 18:54 UTC (Fri) by lethalman (guest, #53313) [Link]
Please notice there's also another firefox extension in the mozilla addons website that does this (differently but it does): http://decrew.indivia.net/sslguard/index.html
Using HTTPS Everywhere with LWN.net Posted Jun 18, 2010 19:01 UTC (Fri) by intgr (subscriber, #39733) [Link] If you want to browse lwn.net securely, then install this extension and create the file: ~/.mozilla/firefox/$PROFILE_NAME/extensions/https-everywhere@eff.org/chrome/content/rules/LWN.xml with content:<ruleset name="LWN"> <rule from="^http://lwn\.net" to="https://lwn.net"/> <rule from="^http://www\.lwn\.net" to="https://www.lwn.net"/> </ruleset>Enjoy!
Using HTTPS Everywhere with LWN.net Posted Jun 18, 2010 21:11 UTC (Fri) by cesarb (subscriber, #6266) [Link]
According to https://www.eff.org/https-everywhere/rulesets, shouldn't it be put at HTTPSEverywhereUserRules/?
Using HTTPS Everywhere with LWN.net Posted Jun 18, 2010 22:01 UTC (Fri) by intgr (subscriber, #39733) [Link] You are right, I didn't read that article carefully enough. Also the second rule should be <rule from="^http://www\.lwn\.net" to="https://lwn.net"/> because LWN doesn't have a certificate for the "www" subdomain.
Subtle problems (was: Using HTTPS Everywhere with LWN.net) Posted Jun 19, 2010 1:50 UTC (Sat) by cesarb (subscriber, #6266) [Link]
I started using your rules, but had to disable them a few minutes later. By pure coincidence I was looking for announcements about the ancient TUX in-kernel webserver (to write a sarcastic reply to a comment at another LWN article), and found out that while http://lwn.net/2000/0907/kernel.php3 works, https://lwn.net/2000/0907/kernel.php3 does not (it gives a 404 error).
I suspect this kind of thing is more common than one might think; it is too common to have separate virtual hosts for the non-SSL port 80 and the SSL port 443, and once you have separate virtual hosts it is very easy for their configuration to diverge. And as I just noticed, the differences will be in less often used URLs, meaning that the rule creator will do a quick check and think everything is working fine, while the unfortunate user to hit the problem will incorrectly think it is just bitrot on less used parts of the website ("who uses PHP 3 these days?").
Subtle problems (was: Using HTTPS Everywhere with LWN.net) Posted Jun 19, 2010 7:09 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] Actually it's quite hard to have virtual hosts on port 443. You need SNI which still isn't supported by IE.
Subtle problems (was: Using HTTPS Everywhere with LWN.net) Posted Jun 19, 2010 14:27 UTC (Sat) by paravoid (subscriber, #32869) [Link]
Actually IE supports SNI; it has for a while.
It's just that it needs Vista+ and too many users are still with XP.
https-everywhere from the EFF Posted Jun 18, 2010 19:47 UTC (Fri) by fperrin (guest, #61941) [Link]
> Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site.
You mean, like https://lwn.net where every link is an absolute link to the plain HTTP version ? :-)
(In case you're wondering, I only mind because my workplace as such an aggressive caching server that I sometimes see the version of articles with the comments stopping 48 hours ago. At least in HTTPS, the caching of pages is not possible.)
https-everywhere from the EFF Posted Jun 18, 2010 20:14 UTC (Fri) by dns (subscriber, #4239) [Link]
> You mean, like https://lwn.net where every link is an absolute link to the plain HTTP version ? :-)
I'm not sure I understand this: links offsite naturally will be http, but links to other pages within lwn.net seem to be https.
I tested this by adding lwn.net to my NoScript Options|Advanced|HTTPS|Behaviour page. Seems to work, for LWN and also for www.google.ca and www.google.com (but not other google sites, e.g. news).
https-everywhere from the EFF Posted Jun 18, 2010 20:23 UTC (Fri) by corbet (editor, #1) [Link] We have a mixture of absolute and relative internal links; the absolute ones will be http. We've thought about going all-https for a while; we've just never had the time to really think it through.
https-everywhere from the EFF Posted Jun 18, 2010 20:28 UTC (Fri) by eli (subscriber, #11265) [Link]
Count me as a vote for https. My own blog is setup to redirect http to https.
https-everywhere from the EFF Posted Jun 19, 2010 0:24 UTC (Sat) by ewan (subscriber, #5533) [Link]
I really can't see the point of encrypting a connection to LWN (logins aside, obviously). It doesn't disguise the fact that you're connecting to LWN, it doesn't protect anything confidential since everything on the site is pretty much public.
I can see advantages in browsing via Tor, and I can see full time https being useful for webmail, online document editors etc. to conceal the contents of the documents, but on a site like LWN all it gets you is the marginal advantage of preventing an observer knowing which particular pages you're accessing. Is it really worth the encryption overhead just for that?
https-everywhere from the EFF Posted Jun 19, 2010 1:04 UTC (Sat) by cesarb (subscriber, #6266) [Link]
The cookie your browser is sending to the LWN servers is not public at all.
It is sent with every HTTP request you make to lwn.net. It is also what the server uses to authenticate a user posting a comment.
If someone can see the cookie your browser sent to the lwn.net server, that is all he needs to reply to one of your comments as yourself, with a message starting with "DISREGARD THAT".
https-everywhere from the EFF Posted Jun 19, 2010 8:41 UTC (Sat) by NikLi (guest, #66938) [Link]
Are you aware of the fact that an url can be
<a href="//lwn.net/path/file.html">article</a>
and with this form the protocol can be either http or https
https-everywhere from the EFF Posted Jun 19, 2010 12:43 UTC (Sat) by erwbgy (subscriber, #4104) [Link] This is useful information. Thank you.
Entropy Posted Jun 18, 2010 20:53 UTC (Fri) by tamasrepus (guest, #33205) [Link]
Something I've been wondering with this rage to encrypt all HTTP communications—where does the entropy come from for creating all the SSL session keys?
Most servers, especially relatively low-traffic ones and especially virtual machines, do not have good entropy sources and run out relatively quickly. Is overuse of HTTPS going to create a false sense of security because keys used being generated are no longer random?
Entropy Posted Jun 18, 2010 21:18 UTC (Fri) by chad.netzer (✭ supporter ✭, #4257) [Link]
http://www.openssl.org/support/faq.html#USER1
Basically, openssl consumes /dev/urandom (ie. non-blocking) PRNG bits, so it probably isn't an issue for devices that stay up for some time, and have at least a minimal amount of "true" entropy to seed it with.
Entropy Posted Jun 19, 2010 2:07 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] The obvious solution is a hardware true RNG. There are plenty of sources of truly random noise- thermal noise, radio static, etc.- that you can use as a source of entropy if it's important. I know that both Intel and Via have included hardware RNGs in quite ordinary systems, and there may be others that I'm not aware of. Lack of good entropy sources for SSL shouldn't be a problem.
Entropy Posted Jun 21, 2010 20:46 UTC (Mon) by nix (subscriber, #2304) [Link]
And thanks to the guys at entropykey.co.uk, true hardware RNGs don't even cost much and are Linux-friendly (I don't think it's *possible* to be more Debian-friendly than they are) and seriously well-designed (hardware and software both).
Every headless server should have one :)
Entropy Posted Jun 21, 2010 20:52 UTC (Mon) by nix (subscriber, #2304) [Link]
Argh. Watch the idiot not read the whole thread. I wish you could delete your own posts on LWN...
Entropy Posted Jun 19, 2010 2:27 UTC (Sat) by pabs (subscriber, #43278) [Link]
There are hardware devices to do this, one of my servers uses rng-tools to grab entropy and pass it to the kernel. Where this doesn't exist you can get a USB device like the Entropy key:
Entropy, peer review and paranoia Posted Jun 19, 2010 12:45 UTC (Sat) by copsewood (subscriber, #199) [Link]
/dev/urandom (if as another commenter pointed out, it is well seeded) has probably been more actively peer reviewed than most hardware entropy sources. This is a PRNG generated using a strong stream cipher seeded (presumably as and when genuine entropy is available) using /dev/random. /dev/urandom is non blocking and is likely to be technically more predictable than a hardware noise source, making it practically less predictable (or controllable) than theoretically better sources which have not been peer reviewed, or whose hardware designers may have been leaned upon depending upon your paranoia level.
Entropy, peer review and paranoia Posted Jun 21, 2010 21:00 UTC (Mon) by nix (subscriber, #2304) [Link]
Well, yes, but if you mix the input from a hardware source into the kernel's, you get the best of both worlds: you can tell the kernel there are as many bits of entropy in there as you feel willing to believe, depending on how much you trust the hardware device, and you get something more random than 'nothing to speak of', which is all you have randomwise on a lot of machines these days (VMs, headless machines, especially headless machines with only solid-state storage).
Websites shouldn't give https: links Posted Jun 19, 2010 12:57 UTC (Sat) by bjartur (guest, #67801) [Link]
HTTPS-Everywhere's homepage accuses web page authors that use the http scheme of doing something wrong. A HTTP client that establishes a encrypted (and possibly authenticated) connection to a server but then establishes a new unencrypted one because of the a URI scheme is doing something wrong.
Wether to encrypt the connection should be decided based on user option, announced support in DNS and possibly context (such as whether the request contains a <input type=password> or a Cookie header).
I like the project though.
support RFC 2817? Posted Jul 1, 2010 15:40 UTC (Thu) by jpnp (subscriber, #63341) [Link]
I very much agree with you. It has never seemed right to me that security characteristics were made part of the URL; it is an orthogonal concern.
Many other internet protocols (e.g. SMTP, LDAP) now support TLS upgrade to allow a connections to negotiate secure transport after connection. It is a matter of server and client policy as to whether they will talk without it. RFC 2817 specifies a similar mechanism for HTTP; it is implemented by Apache, but not as far as I can tell any popular browsers. It would be nice to see mozilla support this (https://bugzilla.mozilla.org/show_bug.cgi?id=276813).
It is not clear exactly what the UX for this should be, but if gecko were to have the ability then extension developers would experiment with user controls.
no google images search Posted Jun 19, 2010 16:53 UTC (Sat) by mattdm (subscriber, #18) [Link]
Not this extension's fault, but: google currently doesn't provide their images search over https, so if you install this, you won't be able to easily search for images. Confused me for a bit.
|
|
||||||||||||