5

Despite the fact that you get a big red threatening warning telling you that the certificate has not been verified by one of those certificate authorities or has expired, what is bad with it in comparison to just using HTTP? Is it worse or not?

According to Google Chrome (http://www.sslshopper.com/assets/images/chrome-beta-ssl-2.png) « an attacker may be trying to intercept yours communication ». What makes this browser and almost all others raising this warning in the case of a self-signed/expired certificate (and I did not write a certificate explicitly verified as invalid) and not in the case of browsing with HTTP? Again, is it less secure than browsing with HTTP?

It is clearly more threatening to browse a website with self-signed HTTPS certificate than browsing the exact same website with HTTP so, are those modern browser behaviors a scam to make honest companies buy SSL certificate that they may not need?

5 Answers5

7

Self signed certificates are not strictly worse than certificates signed by a reputable CA, and in all technical ways they are better than plain HTTP.

From the signing and encryption perspective they are identical. Both can sign and encrypt traffic so that it is not feasible for others to snoop or make modifications.

The difference is the way that the certificate is designated as trusted. With a CA signed certificate the user is trusting the set of trusted CAs that they have installed in their browser/OS. If they see a certificate signed by one of these they accept it and everything is fine. If it isn't (such as when self-signed) you get a big scary warning.

The reason this warning is displayed for self-signed certificates is that the browser has no idea who controls the certificate. The CAs that the browser trusts are known for verifying that they only sign the certificates of the web site owner. Therefore the browser, through extension trusts that the certificate's corresponding private key is controlled by the web site operator (and hopefully it is). With a self-signed certificate the browser has no way of knowing if the certificate was generated by the web site owner, or some man in the middle that wants to read your traffic. To be on the safe side, the browser rejects the certificate unless it is proven valid...and you get a big red warning.

The important thing about this warning is that it gives you a way to get information about the certificate. If you know what certificate you expected to get you can trust that certificate, and your browser will let you connect quite happily. This is of course great if you know the certificate you expect to get. It allows you to not even trust any CA (any trusted CA could generate a trusted certificate and intercept your traffic if they wanted to) if you want.

If you don't verify the certificate you are gaining nothing over unencrypted HTTP as anyone between you and the server could just generate their own certificate and you would be none the wiser. This could be considered worse than plain HTTP as us humans with our feeble emotions might be mislead into thinking that our connection is secure, but the only technical downside over HTTP is some wasted CPU cycles.

So for a private site, which only a couple of people access and you can distribute the certificate a self-signed is actually better than a trusted certificate. However, for the public internet you can't expect the users to verify the certificate (how would you securely transmit the details anyways) and if wise they would probably turn and run.

As for expired certificates they aren't really worse than valid ones. The reason certificates expire is so that they are invalid by the time that cracking them becomes feasible (hopefully). So the difference between a certificate that expires tomorrow and one that expired yesterday is negligible. However I would be more than a little concerned about a certificate that expired years ago.

Opportunistic Encryption

If you want to provide a little extra security there is a new standard (that is only implemented in Firefox at the moment).

Opportunistic encryption provides encryption between supporting clients and servers without authentication. It allows you to use a self-signed certificate without generating any warnings.

The reason why opportunistic encryption is better then using a self-signed certificate and HTTPS is that it provides no suggestion to the user that the connection is secure. To a user the connection appears to be a regular unencrypted HTTP connection but under the hood an SSL connection is being used to thwart passive attackers.

Again, if you are actually verifying the self-signed SSL certificate that is the best. But if you are just trying to provide unauthenticated encryption to stop traffic sniffing opportunistic encryption provides the upsides without tricking the user into thinking they are using a secure connection.

Community
  • 1
  • 1
Kevin Cox
  • 3,080
  • 1
  • 32
  • 32
2

After all the comments and further researches, I add my own answer.

I consider that a self-signed and/or expired HTTPS certificates (that raise a warning in the browser) are worse than just using HTTP for the following reason:

When a user is browsing with HTTPS, he/she presumes that it is secure and then the website should return a valid certificate. If it is not the case (self-signed and/or expired HTTPS certificate) then it is not secure. It could be a real threat or a simple problem in the certificate configuration/deployment but still, it is a problem and the user should stop browsing if he/she don’t have more information about this site.

However, there is a situation, in which I found myself today, where a user have more information about the website. Let imagine a small company in which only two employees need to access a website administration platform. If those two employees are aware that the platform does not have a certificate signed by any CAs (Certification Authorities), it is still better to communicate through this unsecured HTTPS than through unsecured HTTP because, at least, the communication is cyphered. Doing this would reduce the attack possibilities even if it does not prevent it.

That said, even if today HTTPS certificate can be delivered freely and quickly, it would have been great, at the time of costly certificates, to have an intermediary protocol between HTTP and HTTPS. A not-less-secure-protocol-than-HTTP where there is no authentication like SSL certificates but where the data is cyphered.

  • 1
    The small company use case you're talking about can be addressed in two ways: (a) the users could add explicit exceptions in their browsers, by verifying manually the certificate the first time against what they know to be correct (Firefox lets you do that) or (b) have the company use its own CA, and install that CA certificate on the user's machines: there are tools to administer your own CA that can help. – Bruno Feb 15 '13 at 11:06
2

Self Signed and Certificate Authority Signed certificates ONLY provide encryption and an HTTPS connection, but that is where the similarities of security end. Unfortunately with self signed digital certificates, only the person who created the certificate from their own server knows anything about it. For example... where is this person storing the key pair? Who else has access to the key pair? How does a visitor know that this is the legitimate owner of the domain? The point is, without having knowledge of the process, a site visitor (even a technically skilled visitor) has no idea how the key pair creating that HTTPS connection has been handled. When site visitors see an HTTPS connection signed by a reputable Certificate Authority such as thawte (owned by Symantec) for example, at least the visitors know that the domain ownership was verified and the signing credentials are highly secured by a trusted authority.

Secure128
  • 21
  • 2
  • 2
    Even when the certificate is issued by a common CA, the user has no guarantee how the server's key pair has been handled. – Bruno Feb 15 '13 at 11:07
  • Understood Bruno, but I think it's fairly safe to assume a CA is handling their signing credentials with the utmost integrity (in most cases). I'm referring to the signing CA itself not the completed key pair, sorry for not clarifying. It's kind of like having a notary public give a sealed stamp and signature to witnessing a document signing. – Secure128 Feb 15 '13 at 17:54
1

A self signed certificate is functionally equivalent to a signed one (assuming the same key length). The inherent security is the same. However, that's not to say that it provides the same level of security to the end user since they have no way of knowing who signed the certificate or if it should be trusted.

It's no easier for the ISP (or any one) to read communication sent with a self signed as it is with a certificate authority signed one.

yohaas
  • 126
  • 4
  • Thanks. Yes I just read this [comment](http://stackoverflow.com/a/514243/1919510) from @ClintHarris and he explains it in details in the article mentioned. However, my question really is about differences between HTTP and self-signed HTTPS certificates, not about differences between self-signed HTTPS certificates and CA-signed HTTPS certificates. –  Jan 22 '13 at 18:06
  • So did the article clear the difference up? HTTP sends everything in plain text and is vulnerable to sniffing. HTTPS (self signed or otherwise) encrypts before sending. – yohaas Jan 22 '13 at 19:58
  • I guess you are right and that is why I don't understand why a browser would scare a user going to a website with self-signed HTTPS certificate while the same browser is happy not saying anything to the same user going to the same website but with HTTP this time. –  Jan 22 '13 at 20:54
  • That's a valid point. I guess the difference would be that while on HTTP there is no presumption of security, while on HTTPS with a self signed cert, there may be the presumption that it's secure, so the browser is warning you that it may not be. – yohaas Jan 22 '13 at 23:12
  • Yes that is right, but I guess it only concerns the minority of experienced and technical people. I think it would hurt more than it helps the big majority of normal people that are inexperienced with web technologies. Developers being aware of the warning threat in the browsers, some of them and particularly small website developers might stick to HTTP instead of taking the plunge and pay for SSL certificates. So, at the end, are those technical choices from browser editor companies a real progress for people in term of security? –  Jan 23 '13 at 07:44
  • I come back on your comment because I think I missed something about the SSL protocol. If I get it right, the SSL protocol can only tell that a given certificate is signed or not signed by a given CA? It cannot tell that a given certificate is compromised in itself but can only tell that it may have been compromised because it is not signed by any of the CAs in the CAs collection of your browser? Does that make sense? –  Jan 23 '13 at 08:44
  • Yes, if it's not signed by one of the CA that it knows about then it will give the warning. To your general point about SSL, I don't really agree. I think that people expect there to be HTTPS when submitting sensitive info, and would avoid places that try to take it over HTTP. The cost of SSL certs has gotten so cheap that it's not a barrier to having one. – yohaas Jan 23 '13 at 14:38
0

yes, websites which use self-signed certificates are not registered nor verified - attackers can just swap the certificate and pretend to be the website - being used to click away these warning you will not notice the difference.

SSL certficates are free nowadays, every "webmaster" who doesnt use these services is ... incompetent, in fact you should avoid these sites.

are those modern browser behaviors a scam to make honest companies buy SSL certificate

like i said : certificates are free, the webmaster only needs to register - which is done in less than 20 minutes.

Again, is it less secure than browsing with HTTP?

in some ways : yes because it "trains" users to ignore very important warnings

specializt
  • 1,913
  • 15
  • 26
  • Thanks. Which sites should I avoid? In which way it is an important warning, I mean it is still better than using just HTTP, isn't it? –  Jan 22 '13 at 16:48
  • I read it again and I know that it would not prevent attackers to swap the certificate and pretend to be the website but this is not my point. I am not trying to tell that self-signed is secure, I am trying to know if self-signed HTTPS certificates are less secure, technically speaking, than HTTP. –  Jan 22 '13 at 16:56
  • 1
    using a security mechanism which is easily exploited and - in fact - even provokes exploitation lowers the total system security. Unsecured systems have at least the advantage of being one-in-many and need not be checked / counterchecked thus can be routed more efficiently. More efficient routing will result in a **miniscule** security-advantage because the packets travel faster / more efficient hence the manipulation will be more difficult ... even though modern hardware is very able to cope with that; manipulations on a large scale will definitely be more difficult. – specializt Jan 22 '13 at 17:05
  • I don’t know if this minuscule security-advantage takes precedence over an unsecured but still cyphered communication. Is a HTTPS communication with a self-signed certificate differentiable from one with a verified certificate, from the perspective of a too curious internet service provider for example? –  Jan 22 '13 at 17:15
  • yes of course - the SSL-handshakes and the **public** certificates are unencrypted, every ISP is able to read and/or verify them. With ISP-databases, this should be a very fast lookup - even simple text-matching will reveal the difference -- officially signed certificates arent signed by the domain itself ;) – specializt Jan 22 '13 at 17:28
  • As you are pointing in your answer, there certainly are some « incompetent » « webmasters » which would buy an expensive certificate while they could get one for free. So, that makes a very lucrative market for those certificate authorities to take advantage of those « incompetent » people. Apart from that, are these expensive CAs offering any additional services related to the security itself (I am not talking about non-security-related things like insurance)? From the normal user perspective, what can he expect, in term of trust, from a CA that delivers certificate to anyone for free? –  Jan 22 '13 at 21:24
  • he can expect to be known as real citizen (or registered company) to a verified authoritative instance, he can expect his certificate working in every browser in every version, he can expect his personal details being shown 100% correctly AND he especially can expect the data transfer being without manipulation, observation (above the network layer) or deceleration of any kind - registered certificates in SSL-streams get a higher priority in regards of congestion control & traffic-shaping - such websites will be delivered at optimal performance, if possible. – specializt Jan 22 '13 at 23:00
  • Oh sorry, my question was not clear enough. By « normal user », I meant non-technical people like grand’ma, not website owners or developers. So, what trust can these normal people expect from a CA by knowing that this CA delivers certificate to anyone for free? –  Jan 23 '13 at 07:34
  • ... the certificate, what else. Your questions must be the most weird ones i have read in the past 12 months – specializt Jan 23 '13 at 11:50
  • I am not clear enough then ;-) Of course the certificate, but what is the VALUE that a normal user can expect of such certificate? Certificates are all about trust and delegation of trust. If a CA trust a website and you trust the CA then you trust the website, right? But what logical VALUE can you grant to a CA that gives anyone a certificate for free, despite the technical details being perfectly ok (green light on the browser, closed padlock, ...)? –  Jan 23 '13 at 13:16
  • Imagine a real life example, you want to do business with Bob but you don’t know Bob. However you know Alice a little bit. Case #A: Alice tells you that she thinks Bob is a good guy because she knows him a little bit. Case #B: Alice tells you that she thinks Bob is a good guy because she knows him very well and speaks about him their last week-end together during two hours non-stop. Don’t you see a difference between case #A and case #B in the way you gonna trust this Bob guy? –  Jan 23 '13 at 13:17
  • paid certs have a higher level of trust. And your point being? – specializt Jan 23 '13 at 13:54
  • I have no point, I am just trying to understand, as a developer, the mechanisms behind all the HTTPS stuff and, if I need to get a certificate from a CA and why: to really enforce security or just to disable browsers warnings, and also to understand if I should get a free one or if I should pay for it and why, again. I guess that is what you are calling « competent webmaster » which are not just getting HTTPS because everyone tells it, but which are first trying to understand the concepts to make a good decision. –  Jan 23 '13 at 14:27
  • interesting .... well, free certs are a good way to start, deploy & test your setup. If you're satisified with the CA you got the cert from you might as well get a paid cert one day. Until then, a free one will be equal to the paid one, its just the level of trust which differs in that case. Really expensive certs come with the green URL-bar and that looks really trustworthy from the viewpoint of end-users and/or customers so you could gain a few more of them .... probably. – specializt Jan 23 '13 at 15:48
  • Ok, thanks. And I guess that the expensive certificates are not just deliver within 20 minutes by a totally unknown customer of the CA? Does the CA perform a real investigation on the customer to truly identify it and to better reflect the trustworthy indicators in the web browsers ? –  Jan 23 '13 at 15:56
  • 1
    free certs are actually delivered within 20 minutes - they only verify your domain, e-mail on that domain and thats about it ... of course the level of trust is rather low in that case BUT your visitors will not receive any warning about the cert anymore - Its a real certificate with strong encryption and valid data in it. – specializt Jan 23 '13 at 16:09