×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox Extension HTTPS Everywhere Does What It Sounds Like

timothy posted more than 3 years ago | from the effin'-sweet dept.

Firefox 272

climenole writes "HTTPS Everywhere is a Firefox extension produced as a collaboration between The Tor Project and the Electronic Frontier Foundation. It encrypts your communications with a number of major websites. 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

272 comments

noscript? (3, Informative)

Cmdr-Absurd (780125) | more than 3 years ago | (#32611540)

noscript has a means of doing this on a per-site basis. Wildcards are accepted.

Re:noscript? (1)

Jojoba86 (1496883) | more than 3 years ago | (#32611622)

I did not know that. However at least this user-friendly extension from the EFF will hopefully be a better solution for less technically inclined people, and be able to raise awareness of the difference between using http and https.

Does NOT work for Slashdot.org (5, Interesting)

Anonymous Coward | more than 3 years ago | (#32611738)

Unfortunately. No https for slashdot.org - why not Slashdot? Comments on politically orientated stories from "sensitive" countries does not deserve to be encrypted? You should know better Slashdot

Re:Does NOT work for Slashdot.org (4, Informative)

Lingerance (1117761) | more than 3 years ago | (#32611780)

That's a subscriber feature.

Re:Does NOT work for Slashdot.org (0)

Anonymous Coward | more than 3 years ago | (#32611814)

That's a subscriber feature.

That's a money saving feature. Fixed that for you.

Re:Does NOT work for Slashdot.org (5, Insightful)

FriendlyLurker (50431) | more than 3 years ago | (#32611844)

That's a subscriber feature.

So to narrow down people posting politically sensitive stories (say, whistle-blower type stories) from a country, it is merely necessary to cross check banking records against payments to Slashdot. Slashdot should know better.

slashdot, HTTPS please! (1, Interesting)

Anonymous Coward | more than 3 years ago | (#32612126)

Mod parent up.

We know HTTPS isn't "cheap". But seriously, now would be the time for /. to offer TLS.

I didn't know either (1)

Burz (138833) | more than 3 years ago | (#32611776)

...and I use NoScript regularly :)

Still, for those of us who setup systems and browser for other people, a simpler extension like HTTPS Everywhere will help immensely.

It is based on NoScript, in fact (5, Informative)

Anonymous Coward | more than 3 years ago | (#32611778)

From TF (and missing) A [eff.org]:

Our code is partially based on the STS [wikimedia.org] implementation from the groundbreaking NoScript [noscript.net] project.

Re:noscript? (1)

himitsu (634571) | more than 3 years ago | (#32612404)

Thank you sir! I've been looking for another extension to force the Firefox searchbar to user Google SSL for 30 minutes now.

Why install another extension when I already have good old NoScript.

Feature not news worthy ... (-1, Troll)

Anonymous Coward | more than 3 years ago | (#32611544)

Its only useful for security nuts and fags!

NoScript has done this for years (5, Informative)

Coopjust (872796) | more than 3 years ago | (#32611554)

http://noscript.net/features#options [noscript.net]

Preferences for enhancing HTTPS behavior and cookies:
Force the following sites to use secure (HTTPS) connections - a space-separated list of site patterns

Then again, if you don't trust the NoSript author after the controversy [techjaws.com], this might be a good alternative. I figure NoScript is under more scrutiny than any other extension and the author learned his lesson.

forcing views of the hompage (5, Informative)

SuperBanana (662181) | more than 3 years ago | (#32611688)

I don't care about ads on his site.

I care about being forced to update NoScript every few days, each time being forced to load his site. I've got another extension, a Flash downloader that does the same thing. They're both either the world's worst programmers, or they're intentionally releasing updates just to drive traffic to their homepages.

It's also incredibly irritating to get interrupted almost every time I go to restart Firefox!

Re:forcing views of the hompage (0)

Anonymous Coward | more than 3 years ago | (#32611716)

I can see why noscript has frequent updates, since it's in an arms race with malware writers, so let's not immediatly assume the worst.

Re:forcing views of the hompage (1)

clone53421 (1310749) | more than 3 years ago | (#32611728)

I can see why noscript has frequent updates, since it's in an arms race with malware writers

So is AdBlock Plus, and it manages to provide a delivery system that doesn’t require frequent updates to the extension itself.

Furthermore you innately don’t need to update a whitelist as often as a blacklist.

Re:forcing views of the hompage (2, Insightful)

rlk (1089) | more than 3 years ago | (#32611830)

AdBlock Plus and NoScript are doing different things -- ABP is basically a filter engine, and the rules are the only thing that (normally) needs to be updated. NoScript is blocking things based on various algorithms, so it's procedural rather than data-driven. It's not surprising that NoScript's engine needs to be updated more often than ABP's.

Re:forcing views of the hompage (1)

fast turtle (1118037) | more than 3 years ago | (#32612044)

That's what I've never understood. All Noscript has to do is disable scripting across the board. Then enable it on a Site by Site (Whitelist) basis. What's so f""ing hard about that? That's my settings by default. It blocks everything except those websites where I must have scripting enabled and I use the same settings for my 70+ mum and my 50+ sis (both of them are Noobs)

Re:forcing views of the hompage (5, Informative)

Anonymous Coward | more than 3 years ago | (#32611724)

From the FAQ [http://noscript.net/faq]:

2.5
Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
A: First time you install NoScript and every time you upgrade it to a newer major version, Firefox opens an additional tab containing the NoScript welcome page, where you can read the release notes, the latest announcements and an introduction to the most important NoScript features (plus a link to this very FAQ...)
If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.
Notice that if the above "fix" doesn't work or, worse, you keep being redirected on the welcome page every time you restart Firefox, chances are there's something (like a buggy extension) preventing your preferences from being saved: you may need to follow this advice, then.

Re:forcing views of the hompage (3, Informative)

Coopjust (872796) | more than 3 years ago | (#32611730)

http://noscript.net/faq#qa2_5 [noscript.net]

Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.

He's intentionally driving traffic to his page, but you can disable it easily (it used to require about:config, but it was a boolean that was fairly easy to find).

Re:forcing views of the hompage (1)

MokuMokuRyoushi (1701196) | more than 3 years ago | (#32612230)

I'm not sure if anyone ha said it yet, so here goes - who cares? It takes me less than thirty seconds to update, load FF, and close the NoScript tab that open. Its a very small price to pay for an important extension. Yes, the programmers may be farming homepage traffic - but as long as I've got an up-to-date, free version of an impressive script-blocking-extension... I don't give a rats ass. Take all the web traffic you want, mate.

Re:forcing views of the hompage (1)

mkremer (66885) | more than 3 years ago | (#32612306)

Have you tried unchecking the display release notes after update on the notifications page to not load his site after a update?

NoScript over-engineered (0)

Anonymous Coward | more than 3 years ago | (#32611974)

NoScript is overly complex, and so is flashblock for that matter. I view them both as solutions looking for problems.

There is a simple, elegant tool which does either job better, and then gets the hell out of your way: QuickJava [mozilla.org]. Click the button, javascript off. Same as if you disabled it in the Tools menu, the way it should be. Not "mostly" off, but OFF. Click it again, javascript on. Click the flash button, flash plugin disabled. Click it again, re-enabled.

Now THAT is the correct solution to the problem.

Re:NoScript over-engineered (1)

Dan Ost (415913) | more than 3 years ago | (#32612146)

So how do you handle multiple tabs, some where you want to allow javascript, some where you don't?

Noscript's whitelisting approach handles this cleanly and easily.

Re:NoScript over-engineered (0)

Anonymous Coward | more than 3 years ago | (#32612248)

So how do you handle multiple tabs

I switch tabs, then click the QuickJava button. Where's the problem?

Whitelisting is work. I don't need more work. I just want to disable javascript, no questions asked.

Default to HTTP? (5, Insightful)

SpazmodeusG (1334705) | more than 3 years ago | (#32611558)

Geez. What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.

https://www.slashdot.org/ [slashdot.org]

Re:Default to HTTP? (0)

nedlohs (1335013) | more than 3 years ago | (#32611640)

HTTPS is hearder on the server.

slashdot has exactly zero stuff that needs encrypting. Yes, including slashdot login/password details.

So that makes perfect sense.

Re:Default to HTTP? (2, Insightful)

Anonymous Coward | more than 3 years ago | (#32611660)

So I guess you'd be ok with just telling me your login and password, rather than making me go through the effort to sniff them, right?

I eagerly await your response.

HTTPS costs money (0, Flamebait)

tepples (727027) | more than 3 years ago | (#32611674)

Anonymous Coward wrote:

So I guess you'd be ok with just telling me your login and password, rather than making me go through the effort to sniff them, right?

So I guess you'd be OK with buying an SSL certificate and an SSL-compatible (unique IPv4 address) hosting plan for every blog, forum, and wiki out there, right?

Re:HTTPS costs money (1)

Burz (138833) | more than 3 years ago | (#32611966)

The nice thing about the extension is that it WILL lead to more demand of HTTPS from users because it makes clear to them when the HTTPS option isn't there. They are bound to think more about the sensitivity of their various browsing activities on a page-by-page basis, so the desire for security will find greater expression.

FWIW, maybe the extra demand will lead to people using free CAs for things like blogs. Maybe even EFF could eventually become a CA...

No name-based virtual hosting (1, Informative)

tepples (727027) | more than 3 years ago | (#32612144)

FWIW, maybe the extra demand will lead to people using free CAs for things like blogs.

It's not just the SSL certificate that costs money. The hosting plan also has to support a unique IP per plan because HTTPS is incompatible with name-based virtual hosting. Specifically, HTTPS requires that the server send the correct certificate before even seeing the Host: header, which means the server has to choose based on the incoming connection's IP address.

Re:No name-based virtual hosting (1)

Spad (470073) | more than 3 years ago | (#32612410)

Specifically, HTTPS requires that the server send the correct certificate before even seeing the Host: header, which means the server has to choose based on the incoming connection's IP address.

Not True [wikipedia.org]

Re:No name-based virtual hosting (1)

El_Muerte_TDS (592157) | more than 3 years ago | (#32612438)

And if you read that page you'll notice that a large part of the world has no support for it (most browsers don't support SNI on Windows XP).

Re:No name-based virtual hosting (1)

GigsVT (208848) | more than 3 years ago | (#32612468)

"Internet Explorer 7 (Vista or higher, not XP) or later"

This is a sticky point. Everyone still uses XP because Vista and 7 suck.

Re:HTTPS costs money (1)

Dan Ost (415913) | more than 3 years ago | (#32612154)

Maybe even EFF could eventually become a CA...

I've seen this suggested multiple times. Any idea what the EFF's position is on this?

Re:Default to HTTP? (1, Funny)

Anonymous Coward | more than 3 years ago | (#32611696)

If you're on a network that my traffic to and from Slashdot passes through, knock yourself out. It will give you the ability to post as me, but not much more.

Oh, wait, you are already posting as me. Bastard.

Re:Default to HTTP? (2, Interesting)

icebraining (1313345) | more than 3 years ago | (#32611792)

If anyone wants to protect his/her login data, why don't they use OpenID and a secure provider?

Re:Default to HTTP? (1)

nedlohs (1335013) | more than 3 years ago | (#32612284)

Surely that still results in a cookie that can be snooped over the HTTP stream and used as a login token?

Re:Default to HTTP? (0)

Anonymous Coward | more than 3 years ago | (#32612298)

So I guess you'd be ok with just telling me your login and password, rather than making me go through the effort to sniff them, right?

I eagerly await your response.

User: Anonymous Coward
Password: hunter2

Re:Default to HTTP? (1)

nedlohs (1335013) | more than 3 years ago | (#32612314)

Why would I do that. You do realise that security isn't black and white.

There are levels of security.

My online banking details are something I wouldn't send over HTTP, and yet I'm perfectly willing to send my slashdot details over HTTP.

It's possible to get my online banking details, they are not perfectly secure. It is just more difficult than if I logged into my bank via HTTP.

It's possible to get my slashdot details, they are not perfecctly secure. It is just more difficult than if I posted them in a slashfot post.

In this case the cost/benefit is on the part of slashdot. They bear the cost of paying for the extra resources to do HTTPS on their traffic. There's a benefit to them as well, if login credentials were exposed it would reduce the popularity of the site since a lot of the content generating users would go away if anyone could use their account at anytime.

And simple cookie login tokens over HTTP is enough security so that they don't go away. There's no need to pay for more.

Do you also think slashdot should send every user an RSA SecureID hardware token?

Re:Default to HTTP? (4, Insightful)

Burz (138833) | more than 3 years ago | (#32611868)

O RLY?

Try using Slashdot (or most other sites) all day in an airport or at a cafe with your laptop, then see how long it takes for someone to start F-ing around with the Javascript that your browser is receiving in the clear. And then there are those lovely residential ISPs that screw with your web pages for not very different reasons.

The EFF wants to see the web prepared for an assault that looks likely to intensify.

BTW, there is such a thing as being too cheap.

Cipher CPU use, caching, and Google Custom Search (2, Insightful)

tepples (727027) | more than 3 years ago | (#32611670)

What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.

Once the user has logged in, there are three reasons to switch back to HTTPS for any page that doesn't take credit cards or the like:

  • The ciphers in HTTPS take a not insignificant amount of CPU time. Not all web applications are database- or network-bound.
  • HTTPS isn't cacheable by intermediate transparent proxies, such as those used by dial-up or satellite Internet providers.
  • Google has not released a version of the Google Custom Search box that works on HTTPS sites. The last time I tried it, IE would show the mixed-content alert: "Do you want to display only the webpage content that was delivered securely?" I had to add a workaround to a shopping site that disables Google Custom Search when the user is browsing in HTTPS mode.

Re:Default to HTTP? (1)

suso (153703) | more than 3 years ago | (#32611682)

Maybe its because they want more control over what clients are doing? Using SSL consumes more CPU you know, on both the client and the server side.

As a sysadmin for a web hosting provider, I see lots of these types of extensions that are written with no consideration of the server side of the equation. The people writing them seem to think that the server side has infinite CPU, RAM and bandwidth, which is just not true.

Re:Default to HTTP? (1)

e2d2 (115622) | more than 3 years ago | (#32612008)

Poorly written because it defaults to HTTP? I disagree. Programmers like myself avoid using HTTP for delivering things that simply don't need to be encrypted. Why? Because it's more resource intensive on both the server and the client. We use the optimal solution - HTTP.

Link? (2, Informative)

Anonymous Coward | more than 3 years ago | (#32611560)

For those of you without google ... http://www.eff.org/https-everywhere

Re:Link? (2, Insightful)

Meneth (872868) | more than 3 years ago | (#32611794)

EFF says:

In an ideal world, every web request could be defaulted to HTTPS

I say:
In an ideal world, you wouldn't NEED to use HTTPS.

Much needed extension (5, Informative)

Jojoba86 (1496883) | more than 3 years ago | (#32611564)

Oh wow, this is awesome. I've used greasemonkey scripts with facebook but it's pretty ugly, seems to load the http page before the https page. This sounds perfect. Here's the link https://www.eff.org/files/https-everywhere-latest.xpi [eff.org] which is missing from TFS.

Re:Much needed extension (5, Funny)

Fnkmaster (89084) | more than 3 years ago | (#32611616)

Hmm... if you are trying to encrypt your communications with *Facebook* something tells me you are worrying about the wrong people getting their hands on your personal data.

Re:Much needed extension (0)

Anonymous Coward | more than 3 years ago | (#32611734)

Or maybe he doesn't want the firewall at work reading his personal communication.

Re:Much needed extension (1)

denmarkw00t (892627) | more than 3 years ago | (#32611820)

I'm sorry, but while OP may be concerned about Facebook, it's naive of you to think that s/he has separate passwords for other sites vs. FB - remember, we're talking about someone on the internet. I even use the same password in some places, but regardless it's either SSL login or no login or, if its somewhere I really want to login (/. for example), I use a username/password combo that I don't use anywhere else. Security's role shouldn't be diminished just because of the site you're going to - if there is a login box, HTTPS should be offered, because some people, like their passwords, refuse to change.

Re:Much needed extension (1)

tepples (727027) | more than 3 years ago | (#32611900)

if there is a login box, HTTPS should be offered

The certificate company and the hosting company charge annual fees for HTTPS. These are a cost of doing business if you're deriving a significant chunk of revenue from the site. But how should the operator of every little blog and forum afford the annual fees for HTTPS?

Re:Much needed extension (1)

denmarkw00t (892627) | more than 3 years ago | (#32612006)

While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.

Man in the middle (1)

tepples (727027) | more than 3 years ago | (#32612072)

While a very valid point, there is nothing to stop someone from self-signing a cert.

There is also nothing to stop someone from performing a man-in-the-middle attack on a self-signed HTTPS connection any more than an HTTP connection. You could start your own CA, get the CA's certificate to your users somehow (this is the hard part), and then sign your SSL certificates with that CA's key.

Re:Much needed extension (1)

BarryJacobsen (526926) | more than 3 years ago | (#32612158)

While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.

This was a great suggestion until the major browsers added the "super scary warnings". I've had to walk so many people through exactly what to do in order to get past those. Especially the type of people that say I typed in my password ROSEBUD just like I always do and I got this message. Those errors are too scary for the average user, and require too many clicks.

Re:Much needed extension (1)

Tim C (15259) | more than 3 years ago | (#32612108)

It also stops MITM attacks of course - while it's unlikely that anyone would intercept my latest status update or message and change it in flight, with HTTP it's possible.

(Not that I care, but that's one reason why the OP might.)

Parent's comment isn't really apt (1)

Burz (138833) | more than 3 years ago | (#32612222)

HTTPS usage is at least as much about preventing surreptitious alteration (facilitating 'unwanted features' and attacks) of web pages. This can happen on unsecured or compromised networks: the 'coffee shop' Wifi scene is a place where people are particularly vulnerable not just to sniffing but to intrusion/infection attacks.

Then again, imagine you've been browsing safe at home and what was this tiny extra ad space that your ISP inserted into the top corner of many web pages became slowly larger over a period of months. Before too long the ads take on a TV-screen appearance and a couple years later you are struggling to keep a 1/8 screen sized virtual television (a subject-sensitive enhancement provided by your generous Cable ISP operator!) from impinging on your browsing. Around this point the basic fact that the TV-thing keeps appearing on so many Web users' screens starts to skew the Web advertising market and what once were many independent sites fall prey to a cycle of consolidation under the umbrella of TV networks.

Sounds great, doesn't it?

Saw it on boingboing (1)

pyster (670298) | more than 3 years ago | (#32611578)

Saw it on the boingboing and installed it pronto. I use no script, adblocker, and vadalia (tor), along with some conviences addons that I am sure have their own set of security and privacy issues. Not sure why this addon wasnt just a standard feature all this time on all browsers.

Does what it sounds like... (5, Insightful)

Nick Fel (1320709) | more than 3 years ago | (#32611600)

...except not "everywhere", just major sites.

Re:Does what it sounds like... (1)

icebraining (1313345) | more than 3 years ago | (#32611812)

It probably has to be hardcoded per site - so it can be everywhere, if you help.

Re:Does what it sounds like... (3, Insightful)

Tim C (15259) | more than 3 years ago | (#32612132)

It can't be *everywhere* as not every site provides HTTPS access. You could go through a proxy, but that would only encrypt traffic between you and the proxy (and would of course introduce a potential bottleneck if it was a general-use proxy)

I can't understand... (2, Interesting)

gouttonio (1700654) | more than 3 years ago | (#32611634)

... how does this work without risk of compromising the data at the end of the tor route if the webserver won't accept https. I'll be waiting for SPEEDY which looks like a cleaner way of encrypting everything.

Re:I can't understand... (0)

Anonymous Coward | more than 3 years ago | (#32611770)

Do you mind explaining to the uninitiated among us what exactly SPEEDY is?

Does What It Sounds Like? (4, Informative)

Culture20 (968837) | more than 3 years ago | (#32611652)

It can't work unless these sites already have an https version. If they redirect all 443 traffic to 80 like /., then it does nothing. It might work for facebook since it has a couple pages that allow https, but I'm sure things like their photo servers are probably http only.

Not actually a safety improvement? (0)

Anonymous Coward | more than 3 years ago | (#32611672)

It can't possibly create an encrypted connection to an unencrypted website, so instead of your connection going client->isp->isp->isp->isp->server(in theory all should be reasonably trustworthy), it is going through somebody elses server first. How is that better?

And what about ssl certificates? They tell the user that an audited organisation has identified that the server is authorised by the owner of the domain. If that system breaks(let's say that HTTPS-everywhere users assume that all https sites are valid without checking each certificate) then it has actively decreased the security of the internet for those users.

firefox doesn't really make it easy for the users (5, Interesting)

roman_mir (125474) | more than 3 years ago | (#32611676)

Firefox itself does not really make it easy for the users or for admins to use https everywhere.

I just made a small site, it's for a business, that runs everything through https, I redirect http to https completely. Firefox 3.6.3 on Windows had no problem running the site. IE on windows couldn't open the encrypted pages, Firefox 3.5 on any GNU/Linux distro couldn't open them either, to fix this, I had to add this to /etc/conf.d/ssl.conf : SSLInsecureRenegotiation on

That fixed the IE and FF3.5 on Linux problem.

Here is the description of this flag from apache mod_ssl directive description page:

SSLInsecureRenegotiation Directive
Description: Option to enable support for insecure renegotiation
Syntax: SSLInsecureRenegotiation flag
Default: SSLInsecureRenegotiation off
Context: server config, virtual host
Status: Extension
Module: mod_ssl
Compatibility: Available in httpd 2.2.15 and later, if using OpenSSL 0.9.8m or later

As originally specified, all versions of the SSL and TLS protocols (up to and including TLS/1.2) were vulnerable to a Man-in-the-Middle attack (CVE-2009-3555) during a renegotiation. This vulnerability allowed an attacker to "prefix" a chosen plaintext to the HTTP request as seen by the web server. A protocol extension was developed which fixed this vulnerability if supported by both client and server.

If mod_ssl is linked against OpenSSL version 0.9.8m or later, by default renegotiation is only supported with clients supporting the new protocol extension. If this directive is enabled, renegotiation will be allowed with old (unpatched) clients, albeit insecurely.
Security warning

If this directive is enabled, SSL connections will be vulnerable to the Man-in-the-Middle prefix attack as described in CVE-2009-3555.
Example

SSLInsecureRenegotiation on

The SSL_SECURE_RENEG environment variable can be used from an SSI or CGI script to determine whether secure renegotiation is supported for a given SSL connection.

I wonder if there are other ways of making this work with my other directives:

SSLEngine on
SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5

SSLVerifyClient none - I am thinking about switching it to 'require' right now, but will have to test all browsers with it again, but have to do it I think.

Oh, and getting it all to run together with apache httpd with mod_ssl + mod_jk + apache tomcat is quite a hassle.

But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.

Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.

Can this be looked at, because I am SURE this prevents various sites from using encrypted traffic in the first place and it is a BAD thing, not a good one. All traffic needs to be encrypted, but especially user name/password traffic shouldn't be sent around in plain text.

Name it what it is: an exceptional case of using security to encrypt traffic, a case where the site may not necessarily be what it wants to be seen as, but at least the traffic is actually encrypted. It's terrible if someone comes to your site just to see: SSL ERROR on it, OF-COURSE admins don't want THAT message to be shown on their sites, why do you think so few sites do security properly?

Self-signed certs are vulnerable to MITM (5, Interesting)

tepples (727027) | more than 3 years ago | (#32611740)

It is not an error to run a site with a self-signed certificate

A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser. One workaround is to start your own CA, sign its root certificate with PGP, and distribute that cert to your users to install. But then that starts to depend on the PGP web of trust, which in turn depends on air travel to get keys signed.

Re:Self-signed certs are vulnerable to MITM (1)

roman_mir (125474) | more than 3 years ago | (#32611766)

It is still not an error of SSL or of the site, it is a configuration choice.

Re:Self-signed certs are vulnerable to MITM (1)

bunratty (545641) | more than 3 years ago | (#32611854)

Yes, it is a configuration choice. With that configuration choice, Firefox cannot determine that it's communicating with the site it thinks it's communicating to, and warns the user about the potential security problem.

Re:Self-signed certs are vulnerable to MITM (1)

roman_mir (125474) | more than 3 years ago | (#32611894)

This is not an error of ssl or of http, this should come with a warning from a browser, no question, but my users will know the site and the cert.

I completely disagree that this should come with a label 'Error'.

It should come with some label like: 'Warning, the certificate is self signed, you better know what it is'.

However you skipped completely the part of my post, where I am talking about the real issue:

SSLInsecureRenegotiation on

which is in itself prone to MITM type of attack, regardless of whether the cert is self signed or authorized centrally.

Re:Self-signed certs are vulnerable to MITM (0, Redundant)

roman_mir (125474) | more than 3 years ago | (#32611816)

It is a configuration choice, not an error, and by the way this directive:

SSLInsecureRenegotiation on

has to be turned on, in case you didn't notice a huge portion of my comment, it already is a problem that can lead to a possible MIM attack but if I don't have it on, then IE does not work and FF 3.5 and probably earlier versions don't work on Linux distros and maybe on Windows (I didn't check.)

It is better to run a https site than http, whether the script is self signed is another matter, but it's not an error, especially given what kinds of clients people still use.

Re:Self-signed certs are vulnerable to MITM (1, Insightful)

Anonymous Coward | more than 3 years ago | (#32611976)

A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser.

That can't possibly be the reason for Firefox's weird behavior, because if you use http instead of https, you don't get the error.

Re:Self-signed certs are vulnerable to MITM (1)

tepples (727027) | more than 3 years ago | (#32612098)

If you use HTTP, the user is assumed to know that a man in the middle could see passwords or payment identifiers. The error message for an unrecognized certificate is there to stop people from assuming HTTPS means a connection free from MITM attack.

Re:Self-signed certs are vulnerable to MITM (1)

Bazer (760541) | more than 3 years ago | (#32612092)

A self-signed certificate may be unsafe but it does imply an intent of privacy.

With effort, and sometimes a trivial amount, one can invade on another's privacy. But we've all made a social agreement to respect privacy; all it takes is a humble token, like a window curtain, to remind us of this. The curtain is just cloth, but it does an excellent job of affording us privacy, because it asserts our intent. That way, if we're able to detect it, we can be certain in knowing that our privacy is violated -- otherwise, any access we didn't think to deny (but would regret later) might accidentally intrude upon us -- and with no ill will from the innocent onlooker! How foolish of us, that we didn't draw the curtain when we had the chance!

Re:Self-signed certs are vulnerable to MITM (1)

tepples (727027) | more than 3 years ago | (#32612170)

A self-signed certificate may be unsafe but it does imply an intent of privacy.

So in other words, a self-signed certificate is security theater [wikipedia.org]. Online criminals by definition don't respect the "social agreement" that you mention. (By the way, whom are you quoting?)

Re:Self-signed certs are vulnerable to MITM (1)

Bazer (760541) | more than 3 years ago | (#32612354)

Security and privacy are two different things. You won't stave off criminals capable of carrying out a MITM with a self-signed certificate. You can, however demonstrate that you intend to keep this session private, just like you would a conversation. If worse comes to worst, you'll have a much easier way of proving ill intent on the part of a misbehaving eavesdropper like an ISP or a shoddy data retention scheme.

Re:firefox doesn't really make it easy for the use (2, Informative)

Culture20 (968837) | more than 3 years ago | (#32611838)

But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.

Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage.

Because to verify a self-signed cert, every user has to call the site maintainer on the phone. Self-signed certs or Corporate CAs are great for in-house use where the sysadmins can install the certs for everyone, but since FF can't tell whether your unrecognized cert is being used to just feed html data to a user, or if the user is being asked to enter something confidential, it can't make a distinction between a reasonable use for self-signed and a MitM attempt. Since bad admins had been training people to "just click okay on the cert" for half a decade, FF took their warning up a notch and made people jump through hoops before they succumb to a potential MitM.

Re:firefox doesn't really make it easy for the use (1)

roman_mir (125474) | more than 3 years ago | (#32611862)

But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.

Re:firefox doesn't really make it easy for the use (1)

Culture20 (968837) | more than 3 years ago | (#32611884)

But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.

It _is_ just a warning. If the user knows the cert info (maybe printed on paper in front of him), he can verify it and add it to an exception list. I do that all the time for my own test servers. Firefox doesn't prevent people from connecting with self-signed certs, it just makes them think about the ramifications before they do.

Re:firefox doesn't really make it easy for the use (-1, Redundant)

roman_mir (125474) | more than 3 years ago | (#32611912)

It is in the name: ERROR.

Show a WARNING - Self Signed Certificate.

The language is important if you want any kind of security adoption for many sites.

You better tell me what can really be done about this:

SSLInsecureRenegotiation on

which presents a MITM possible attack with any type of certificate, self signed or not.

Re:firefox doesn't really make it easy for the use (1)

tepples (727027) | more than 3 years ago | (#32611936)

if the user knows the certificate

How would the user know the certificate on the user's first visit to the site?

Re:firefox doesn't really make it easy for the use (1)

roman_mir (125474) | more than 3 years ago | (#32611950)

Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.

so they will also be notified on what the appropriate certificate is.

Re:firefox doesn't really make it easy for the use (1)

tepples (727027) | more than 3 years ago | (#32612054)

Because of my business case - the site is for users who must be first set up by the site administrator

And you can have all these users install your CA certificate when they sign up.

Re:firefox doesn't really make it easy for the use (1)

xaxa (988988) | more than 3 years ago | (#32612094)

Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.

Then I suggest you add the self-signed certificate to their computer, something like this [cacert.org].

security by idiocy is still idiocy, not security (0)

Anonymous Coward | more than 3 years ago | (#32612084)

You, sir, are an idiot.

It *is* an ERROR. Your worthless self-signed certificate can be circumvented by a child, therefore your security is non-existent. The fact that people still use insecure browsers is not an excuse. Two wrongs do not make a right. Find another job, you have failed at yours.

The Firefox folks are doing the right thing by not listening to your moronic suggestions. If they did what you asked then users, using the latest version of the browser mind you, would have no idea that the sites they are visiting are completely insecure and can be hijacked by just about anyone.

Stop repeating your nonsense, no one believes or agrees with you. You suck and have no idea what you are doing.

Security should not be made completely ineffective / impotent just so your personal life can be rendered easier.

'nuff said.

Re:firefox doesn't really make it easy for the use (1)

icebraining (1313345) | more than 3 years ago | (#32611840)

Sending your login/pass to an unauthenticated server is not any better than sending it through HTTP. If you have a MITM, he can be faking the website.

If you want secure login, either get an authenticated cert or use OpenID and let the user choose his provider.

Re:firefox doesn't really make it easy for the use (1)

roman_mir (125474) | more than 3 years ago | (#32611876)

It's not an error, it should be a warning. My users will know the site and the certificate number and this IS how I want the site to work, I don't need a CA or an OpenID to do this, it's not wrong to do.

And it is a million times better than sending plain text over any line any day.

Re:firefox doesn't really make it easy for the use (0)

Anonymous Coward | more than 3 years ago | (#32612100)

You can always write your own browser....

Re:firefox doesn't really make it easy for the use (1)

sinthetek (678498) | more than 3 years ago | (#32612270)

Unfortunately far too many admins (and browser developers) seem to be brainwashed into believing CA's are an absolute necessity. Not everyone is as worried about identification as they are encryption/sniffing by governments and ISPs. Some people simply don't like the idea of trusting the security of their site with a third party (who could still perpetrate or facilitate a MITM themselves using the info you entrust them with) or cannot afford a widely recognized one. I understand a warning but it seems like FF goes too far out of it's way to make scare users away from self-signed certs which results in a LESS secure web as admins opt for the unprotected data xfer rather than scaring off visitors. Just like the use of DULs as a spam countermeasure, the end result is a sort of centralized/classist Internet upon which people can do certain things if they have enough extra $$ to pay for them and are willing to forfeit various freedoms/virtues in return - which runs counter to the idea of a Free and Open Internet.

Re:firefox doesn't really make it easy for the use (0)

Anonymous Coward | more than 3 years ago | (#32611904)

Check out this patch if you need to get rid of SSL/TLS errors: link [mozillazine.org] Beware, it was meant to be used on secure isolated networks, it completely disables checking SSL/TLS certificates and will lie to the user telling them all connections are secure.

facebook (2, Interesting)

aneamic (1116327) | more than 3 years ago | (#32611946)

Am I the only person getting a 'chat is disabled on this page' bubble everywhere when using this plugin on facebook?

Re:facebook (2, Informative)

Culture20 (968837) | more than 3 years ago | (#32612272)

Facebook's chat feature is http-only. My guess is it was a simple way to keep chat from working on the password reset pages (to prevent chat from stealing focus while typing in a password).

I see two things wrong w/ this... (3, Informative)

HTMLSpinnr (531389) | more than 3 years ago | (#32612264)

1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:/// [https], you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?

2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.

To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...