8

When faced by an untrusted certificate, every single browser I know displays a blaring error like this:

Why is that?

This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.

Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?

It looks like I am being misunderstood. I am taking issue with the fact that HTTP sites cannot be more secure than an HTTPS site, even if untrusted. HTTP doesn't do encryption or identification. Phishers can make their sites on HTTP and no warnings are shown. In good faith, I am at the very least encrypting traffic. How can that be a bad thing?

Confluence
  • 1,331
  • 1
  • 10
  • 26
  • 3
    Why does my car make a big deal if I have a door open while driving down the freeway? The warning/caution is usually proportional to the potential danger. Untrusted SSL certs are a potentially big danger. – Matt Greer Sep 30 '10 at 01:45
  • 4
    @Matt This is false analogy. It's more like: my car doesn't do anything if I am not wearing a seatbelt (HTTP), but it starts sounding the alarm if I am wearing a seatbelt (HTTPS). – Confluence Sep 30 '10 at 01:54
  • If you just want to save a few bucks, check out these links: http://www.cacert.org/ | http://www.startssl.com/ – Dagg Nabbit Sep 30 '10 at 02:13
  • 7
    I agree with Confluence. The encryption aspect of SSL should be completely separate from the authentication (identity verification) aspect. Authentication is great for a shopping cart site or something, but really isn't necessary if I'll I'm doing is encrypting a password on a community site. Being forced to pay a third party for the authentication when all I really need is the encryption has been a huge f'n pet peeve of mine for a long time. – Chris Sep 30 '10 at 02:47
  • @Chris, you're missing the point. There's no point using encryption at all if you're not authenticating the server too. You'd otherwise be exchanging secrets with a remote party you can't identify and that could be an impostor (or man in the middle). – Bruno Sep 30 '10 at 10:04
  • 1
    @Confluence, you get your car analogy wrong. If you're in a car with no seat belts (HTTP), then you don't get a warning when you're not wearing it (of course). If you're in a car equipped with seat-belts (HTTPS), you get an alarm when you're not wearing it. – Bruno Sep 30 '10 at 10:17
  • @Bruno, encryption is perfectly useful as a tool on its own. A typical example is the web interface on my load balancer. I want to make sure that if I'm logging in over the web, my credentials are secure, so I need the encryption, but I really have no interest in paying some third party company any sum of money to tell me that I am myself. Of course, you can self-sign a cert for this purpose, but the scenario can easily be expanded to include smaller sites for which validating the identity of the hosting party is quite useless or irrelevant. – Chris Sep 30 '10 at 15:58
  • @Chris, no, encryption isn't sufficient. It's the trust in the certificate (whether via a PKI or a pre-known self-signed cert) that guarantees there's no man in middle. Otherwise, even with encryption, an attacker in the middle could spoof your traffic and you'd have traffic encrypted between You <-> MITM <-> Genuine server (you'd have encryption between you and the MITM and then between the MITM and the genuine server). A self-signed certificate can be sufficient for server authentication, if you've established trust in that certificate by some other means beforehand. – Bruno Sep 30 '10 at 18:13
  • 3
    @Bruno, @Matt, @Confluence: You *all* have the analogy wrong. *Not wearing a seatbelt (HTTP)? No alarm. Wearing a seatbelt inspected by the Federal Highway Administration (HTTPS with trusted certificate) plays pleasant music. Wearing an uninspected seatbelt (HTTPS with untrusted certificate) blares warning sirens, because it may have been manufactured by wankers trying to kill you*. Confluence's point is that wearing a dubious seatbelt (encrypting traffic, even if the endpoint ends up being evil) is better than wearing none (transmitting cleartext to *everyone* along the way to the endpoint). – user359996 Nov 02 '10 at 15:50
  • If you create certificate for your own site and its signed domain that you own, why not trust that? Your password is transferred over secure channel and your certificate CAN be trusted, because its signed by domain owner. But when you use HTTP, everyone can read password. Now we have to pay to get certificate, and even criminals can buy certificates! So why "trusted" certificate is more trusted than your own signed certificate? Certificate companies just make money by selling certs for everyone who are willing to pay.. – newbie Aug 25 '11 at 11:41
  • Browsers should warn about HTTP connection, that MITM attacks might occur, because there is nothing stopping criminals to steal your sensitive data over HTTP connection. "Untrusted" HTTPS at least prevents that. – newbie Aug 25 '11 at 11:48

7 Answers7

9

They do that because a SSL certificate isn't just meant to secure the communication over the wire. It is also a means to identify the source of the content that is being secured (secured content coming from a man in the middle attack via a fake cert isn't very helpful).

Unless you have a third party validate that you are who you say you are, there's no good reason to trust that your information (which is being sent over SSL) is any more secure than if you weren't using SSL in the first place.

Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • But why do they have to show the error? Sure, an "untrusted" cert can't be guaranteed to be more secure than no SSL, but it can't be **less** secure. Conversely, why not show the errors for pages on HTTP? – Confluence Sep 30 '10 at 01:43
  • @Confluence - If you're expecting an untrusted cert, then there is no issue. Ignore the message, move forward, and enjoy the encryption. But if you're going to an e-commerce site, you enter your credit card info, and see an untrusted cert message I would stop (I wouldn't submit that info over regular HTTP either). – Justin Niessner Sep 30 '10 at 01:46
  • I understand that. Techies understand that. But to a regular user (90% of the Internet population) it just looks extremely shady. – Confluence Sep 30 '10 at 01:49
  • 5
    @Confluence - And it is. If you want to be a mainstream site using SSL, use a third party certificate authority and get a real certificate so people know you are who you say you are trying to be. – Justin Niessner Sep 30 '10 at 01:52
  • 1
    @Confluence - the idea is to warn the end user as loudly and clearly as possible that something might be wrong. That's considered to be really important. – Mark Allen Sep 30 '10 at 03:00
5

SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy.

(apache ssl docs)

Yep, I don't see anything about third party certificate authorities that all browsers should recognize as "legit." Of course, that's just the way the world is, so if you don't want people to see a scary page, you've got to get a cert signed by someone the browsers will recognize.

or

If you're just using SSL for a small group of individuals or for in-house stuff, you can have people install your root cert in their browser as a trusted cert. This would work fairly well on a lan, where a network admin could install it across the entire network.

It may sound awkward to suggest sending your cert to people to install, but if you think about it, what do you trust more: a cert that came with your browser because that authority paid their dues, or a cert sent to you personally by your server admin / account manager / inside contact?

Just for shits and giggles I thought I'd include the text displayed by the "Help me understand" link in the screenshot in the OP...

When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party that your computer trusts. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website you intended, and not a third party (such as an attacker on your network).

For a domain mismatch (for example trying to go to a subdomain on a non-wildcard cert), this paragraph follows:

In this case, the address listed in the certificate does not match the address of the website your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Chromium can say for sure that you reached , but cannot verify that that is the same site as foo.admin.example.com which you intended to reach. If you proceed, Chromium will not check for any further name mismatches. In general, it is best not to proceed past this point.

If the cert isn't signed by a trusted authority, these paragraphs follow instead:

In this case, the certificate has not been verified by a third party that your computer trusts. Anyone can create a certificate claiming to be whatever website they choose, which is why it must be verified by a trusted third party. Without that verification, the identity information in the certificate is meaningless. It is therefore not possible to verify that you are communicating with admin.example.com instead of an attacker who generated his own certificate claiming to be admin.example.com. You should not proceed past this point.

If, however, you work in an organization that generates its own certificates, and you are trying to connect to an internal website of that organization using such a certificate, you may be able to solve this problem securely. You can import your organization's root certificate as a "root certificate", and then certificates issued or verified by your organization will be trusted and you will not see this error next time you try to connect to an internal website. Contact your organization's help staff for assistance in adding a new root certificate to your computer.

Those last paragraphs make a pretty good answer to this question I think. ;)

Community
  • 1
  • 1
Dagg Nabbit
  • 75,346
  • 19
  • 113
  • 141
  • Agreed, I think the same and I use self signed certs in both cases - LAN and customers - installing the root cert in their browsers and until now everybody is happy with that because they know the cert will identify my server and will give an alert for another one unless the pirate server owner hacks my DNS and manage to get a trusted cert on my domain and I expect no trusted certificate provider will give one to him! – laurent Sep 30 '10 at 04:52
3

The whole point of SSL is that you can verify that the site is who it says it is. If the certificate cannot be trusted, then it's highly likely that the site is not who it says it is.

An encrypted connection is really just a side-benefit in that respect (that is, you can encrypt the connection without the use of certificates).

Dean Harding
  • 71,468
  • 13
  • 145
  • 180
  • It's not hard to get a legitimate SSL certificate. These errors happen when something is wrong with the cert -- something users should definitely be aware of!! – Chris Thompson Sep 30 '10 at 01:41
  • I am not talking about certs that don't match the domain (yes, that is pretty bad). I am talking about certs signed by authorities not in the browser's trusted CA's (eg: self-signed) – Confluence Sep 30 '10 at 01:41
  • 1
    @Confluence: what's the difference? If I can self-sign a certificate that says I'm "yourbank.com" then why would you *not* expect it to throw up an error? – Dean Harding Sep 30 '10 at 01:42
  • 1
    Since literally anyone can make a self signed certificate, they are very correctly not trusted. – Matt Greer Sep 30 '10 at 01:43
  • @Dean You would have to hijack yourbank.com too in that case. – Confluence Sep 30 '10 at 01:44
  • @Matt See my comment on Justin's answer. – Confluence Sep 30 '10 at 01:45
  • Yes but creating your-bank.com or y0urbank.com is not that hard and still easily fools less technical people. Remember the famous paypa1.com scam? (that's a one not the letter 'l') – Matt Greer Sep 30 '10 at 01:47
  • @Matt There is nothing stopping scammers from creating y0urbank.com and not using any encryption. Regular users (about 90% of the Internet population) would still be blissfully unaware. – Confluence Sep 30 '10 at 01:48
  • That's not the whole point of SSL, though. Part of the point (a big part) is that the data is encrypted so anyone watching stuff go across the wire can't see your passwords, credit card numbers, sensitive emails, etc. This is a huge benefit of SSL, signed or not. – Dagg Nabbit Sep 30 '10 at 02:01
  • @no: it's a benefit, yes, but not the *whole point*. As I said, you can encrypt a socket connection *without* a certificate, but SSL *also* validates the identity of the server as one of it's primary features. – Dean Harding Sep 30 '10 at 02:04
  • Are you saying you can open an http-over-ssh socket without using ssl? If so I'd be very curious to see how that works. – Dagg Nabbit Sep 30 '10 at 02:16
  • @no: no, I'm just saying that encryption is possible without certificates. If the goal had just been about encrypting the connection, then we would have something other than HTTPS/SSL. Since the goal was encryption **and** identification, then we have SSL and certificates. – Dean Harding Sep 30 '10 at 02:18
  • encryption **and** identification ... that was my point, "the whole point of SSL" is not identifying the server, it's also about encrypting your connection to them. You might realize that the server is run by a bunch of underhanded goons but it's still worth it to you to open a connection, as long as nobody else can spy on the transaction... "SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and **encryption for privacy**." (http://httpd.apache.org/docs/2.0/ssl/ssl_intro.html) – Dagg Nabbit Sep 30 '10 at 02:26
3

People assume that https connections are secure, good enough for their credit card details and important passwords. A man-in-the-middle can intercept the SSL connection to your bank or paypal and provide you with their own self-signed or different certificate instead of the bank's real certificate. It's important to warn people loudly if such an attack might be taking place.

If an attacker uses a false certificate for the bank's domain, and gets it signed by some dodgy CA that does not check things properly, he may be able to intercept SSL traffic to your bank and you will be none the wiser, just a little poorer. Without the popup warning, there's no need for a dodgy CA, and internet banking and e-commerce would be totally unsafe.

Sam Watkins
  • 7,819
  • 3
  • 38
  • 38
  • That is not the issue. I am talking about having a self-signed cert matching a domain I own, that a user willingly visits. – Confluence Sep 30 '10 at 01:47
  • @Confluence: How is that situation different from a malicious operator running a site he owns, with a self-signed certificate impersonating an online banking site *that the user willingly visits*? – Greg Hewgill Sep 30 '10 at 01:49
  • 1
    If they didn't warn about your cert, they wouldn't be able to warn about the MITM attack cert either. – Sam Watkins Sep 30 '10 at 01:50
  • @Greg None. But the browser doesn't warn the user when a malicious site is on HTTP either (unless the browser knows it is malicious) – Confluence Sep 30 '10 at 01:56
  • All the browser needs to do to prevent that kind of attack is sound an alarm when the RSA key fingerprint changes (whether or not the cert is signed). An unexpected change from a signed cert to another signed cert is just as sketchy as a change from an unsigned cert to another unsigned, or unsigned to signed, or whatever. The point of getting certified is your name gets put on file somewhere so you can be held accountable for evil stuff you might do with people's data. – Dagg Nabbit Sep 30 '10 at 02:06
  • @Confluence there is no expectation that the communication with an HTTP site will be secure, hence you don't get any specific warning or reinsurance. There is a user expectation for most users that communication with an HTTPS site will be secure: when the safe-guards (i.e. valid cert) are missing, there is a message to indicate something may be wrong. – Bruno Sep 30 '10 at 10:15
2

Why is that?

Because most people don't read. They don't what what https means. A big error is MANDATORY to make people read it.

This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady.

No it doesn't. Do you have any evidence for that? That claim is ridiculous.

This strongly encourages developers and users to know whom they are dealing with.

"fears that users will find the website extremely shady"

What does this even mean? Do you mean "fears that lack of a certificate means that users will find the website extremely shady"?

That's not a "fear": that's the goal.

The goal is that "lack of a certificate means that users will find the website extremely shady" That's the purpose.

S.Lott
  • 384,516
  • 81
  • 508
  • 779
  • 'The goal is that "lack of a certificate means that users will find the website extremely shady" That's the purpose.' Then why aren't these warnings shown to users visiting regular HTTP sites? – Confluence Sep 30 '10 at 02:22
  • @Confluence - You probably *should* get warnings about unencrypted pages, but only for pages with sensitive data. The trick is, how does the browser know if there's any sensitive data? It could look for password inputs, but that wouldn't cover everything. I think with HTTPS the assumption is there's some private data being exchanged, so this puts the browser on high alert for things that look fishy. – Dagg Nabbit Sep 30 '10 at 02:55
  • @Confluence: "Then why aren't these warnings shown to users visiting regular HTTP sites?" Because the certificate's not **wrong**, it's missing. There's a logic problem with presenting an error when (a) there's no certification and (b) no certificate was expected. If you try to use IE in "safe" mode on a non-professional version Windows, you'll see that IE provides all kinds of alerts and warnings at random times and places. The issue is simple logic. `http` has no certification expectation, so there can't be an error. – S.Lott Sep 30 '10 at 11:51
1

Judging from your comments, I can see that you're confused between what you think people are saying and what they are really saying.

Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?

But why do they have to show the error? Sure, an "untrusted" cert can't be guaranteed to be more secure than no SSL, but it can't be less secure.

If you are solely interested in an encrypted connection, yes this is true. But SSL is designed for an additional goal: identification. Thus, certificates.

I am not talking about certs that don't match the domain (yes, that is pretty bad). I am talking about certs signed by authorities not in the browser's trusted CA's (eg: self-signed)

How can you trust the certificate if it is not trusted by anyone you trust?

Edit

The need to prevent man-in-the-middle attacks arises because you are trying to establish a privileged connection.

What you need to understand is that with plain HTTP, there is absolutely no promise of security, and anyone can read the contents passed over the connection. Therefore, you don't pass any sensitive information. There is no need for a warning because you are not transferring sensitive information.

When you use HTTPS, the browser assumes you will be transferring sensitive information, otherwise you would be using plain HTTP. Therefore, it makes a big fuss when it cannot verify the server's identity.

André Caron
  • 44,541
  • 12
  • 67
  • 125
  • My main beef is with the error message. Unencrypted HTTP doesn't do any identification either, but no browser will warn the user about that. – Confluence Sep 30 '10 at 01:58
  • Because HTTP is not encrypted, anybody can intercept the content, so man in the middle attacks make no sense. When establishing a one-to-one encrypted connection, you want to make sure you established the connection with the right person! – André Caron Sep 30 '10 at 02:29
  • 1
    That is exactly my point. HTTP => totally insecure, no warning. HTTPS with untrusted cert => possibly insecure, huge warning. – Confluence Sep 30 '10 at 02:32
  • 1
    But you use https when you need secure conection (at least the user `thinks it is one`) so it needs a warning and http when you don't need one and the `user doesn't expects one` so there is no need of warning. The warning is to alert the user because an https conection is supposed to be secure and identified while on http nobody expects a secure connection. Anyways, even after the message, I think 99% of the users don't know why the connection is not secure (wrong host or not trusted certificate) so the warning has to be big to stop them in all cases. – laurent Sep 30 '10 at 04:29
  • "There is no need for a warning because you are not transferring sensitive information." I beg to differ. Many sites that should be using SSL don't use it. They make people login and transmit their passwords over plain HTTP. Often times these people use the same password for their online banking, and that's "sensitive" enough to me. I would protect my users from eavesdroppers if I could use a self-signed cert, but I can't. See my dilemma now? – Confluence Sep 30 '10 at 07:00
  • This is how the system works, so you play by the rules. The warning is pressure for you to purchase a certificate from a trusted authority. By not paying for the process of identifying yourself with a trusted certificate, you demonstrate your shadiness and the browser reminds the user you are not willing to go through that process. – André Caron Sep 30 '10 at 14:47
0

Why is that?

Because if there's a site that's pretending to be a legit site, you really want to know about it as a user!

Look, a secure connection to the attacker is no damn good at all, and every man and his dog can make a self-signed certificate. There's no inherent trust in a self-signed cert from anyone, except for the trust roots you've got installed in your browser. The default set of trust roots is picked (carefully!) by the browser maker with the aim that only CAs who only act in a way to secure trust will be trusted by the system, and this mostly works. You can add your own trust roots too, and if you're using a private CA for testing then you should.

This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.

What?! You can get a legit certificate for very little. You can set up your own trust root for free (plus some work). Anyone developing and moaning about this issue is just being lazy and/or over-cheap and I've no sympathy for such attitudes.

Ideally a browser would look for information that you want kept secure (such as things that look like credit card numbers) and throw that sort of warning up if there was an attempt to send that data over an insecure or improperly-secured channel. Alas, it's hard to know from just inspection whether data is private or not; just as there's no such thing as an EVIL bit, there's also no PRIVATE bit. (Maybe a pervasive metadata system could do it… Yeah, right. Forget it.) So they just do the best they can and flag up situations where it is extremely likely that there's a problem.

Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?

What threat model are you dealing with?

Browser makers have focused on the case where anyone can synthesize an SSL certificate (because that's indeed the case) and DNS hacks are all too common; what the combination of these means is that you can't know that the IP address you've got for a host name corresponds to the legitimate owner of that domain, and anyone can claim to own that domain. Ah, but you instead trust a CA to at least check that they're issuing the certificate to the right person and that in turn is enough (plus a few other things) to make it possible to work out whether you're talking to the legitimate owner of the domain; it provides a basis for all the rest of the trust involved in a secure conversation. Hopefully the bank will have used other unblockable communications (e.g., a letter sent by post) to tell people to check that the identity of the site is right (EV certs help a little here) but that's still a bit of a band-aid given how unsuspicious some users are.

The problems with this come from CAs who don't apply proper checks (frankly, they ought to be kicked off the gravy train for failing their duty) and users who'll tell anyone anything. You can't stop them from deliberately posting their own CC# on a public message board run by some shady characters from Smolensk[1], no matter how stupid an idea that is…

[1] Not that there's anything wrong with that city. The point would be the same if you substituted with Tallahassee, Ballarat, Lagos, Chonqing, Bogota, Salerno, Durban, Mumbai, … There are scum all over.

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215