9

It wouldn't be far-fetched to guesstimate that at least 50% of the web traffic can be intercepted in 2014.

However, a guesstimate of active interception attacks is likely an order of magnitude lower — probably well below 0,5%, and, apparently, a lot of it is done by the governments, which could potentially have control of certificate authorities anyways, so the value of having a trusted CA chain is questionable.

Since most traffic is intercepted merely passively, meaning that encryption without authentication will let you get away from survaillance and preserve your right to privacy in 99,9% of these cases, why the browser vendors and the https industry effectively still promotes no http encryption over the self-signed https certificates for web enthusiasts like myself?

My emails on a dozen of self-hosted domains is encrypted for free (SMTP STARTTLS), without needing to install any new certs every X months, and without people who email me ever getting any warnings.

(Effectively using ssh likewise doesn't require me to remit any payments to anyone.)

Why my non-commercial web-sites and web-properties cannot do the same?

Community
  • 1
cnst
  • 1,884
  • 2
  • 19
  • 30
  • 1
    Similar to https://security.stackexchange.com/questions/38727/is-a-self-signed-ssl-certificate-much-better-than-nothing and https://security.stackexchange.com/questions/8110/what-are-the-risks-of-self-signing-a-certificate-for-ssl – dave_thompson_085 Jun 29 '14 at 13:56

4 Answers4

7

Since most traffic is intercepted merely passively, meaning that encryption without authentication will let you get away from surveillance ....

It is usually easy to intercept traffic actively if you are inside the same (W)LAN, e.g. by doing ARP spoofing or similar techniques. And, for the parties who are able to intercept the traffic passively on the wider internet it is usually also possible to change or redirect it in some way (like with DNS spoofing) and there are even ISP which modify traffic to inject ads etc.

It is already hard for people to understand the difference between plain HTTP (no encryption), "simple" HTTPS and "better" HTTPS (e.g. extended validation certificates). What you propose here is another level of security, which is slightly better than no encryption and far worse than simple HTTPS, because blindly trusting whatever peer certificate you get makes you just open to easy man-in-the-middle attacks.

Of course, if only few people use a given service you can use self-signed certificates or similar techniques. But in this case you must verify the certificate or public key off-band, like with getting the fingerprint of the certificate or public key some other way and checking it against the fingerprint presented by the connection. This works if you have your own mail server or if you do ssh with hosts you control. But, because you usually don't have an established and secure infrastructure for off-band verification, this will not work for a larger audience.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I see what you're saying -- it's a user interface issue. Still, I'm not suggesting that this new scheme be part of `https` -- I think it should instead be part of the `http` address scheme, and you should merely get it as a bonus, just like you get STARTTLS with SMTP. – cnst Jun 29 '14 at 02:39
  • 1
    @cnst: No, it is the problem of having no way to verify the presented certificate in a trusted way, like you can do with certificate hierarchy and trust anchors (root-CA) which ship with the browser. This cannot be solved with just another user interface. Once you have an established alternative verification path (like with DNSSec) you could do it (and there is already a solution which is called DANE). – Steffen Ullrich Jun 29 '14 at 02:44
  • But it's not a problem with STARTTLS in SMTP; why is it a problem with HTTP? – cnst Jun 29 '14 at 04:12
  • 3
    @cnst: Contrary to HTTP, SMTP is not an end-to-end protocol (e.g. sender-to-recipient), but the mail gets delivered from Mail-User-Agent (MUA) to an Mail-Transfer-Agent (MTA) via SMTP, usually to another MTA via SMTP and then finally to the MTA via IMAP, POP3 or similar protocols. So it never promised end-to-end security, you need PGP or S/MIME for that. That's why most admins of MTA deliver a mail to the next hop even if the connection is not secure (e.g. plain text or without proper identification of the peer), because it is better than not delivering the mail at all. – Steffen Ullrich Jun 29 '14 at 06:13
  • That's kinda exactly my point -- with mail, TLS gets used in practice all the time, yet stuff is guaranteed to not fail if TLS is not available, so, it is theoretically subject to the active attacks, but in practice, it's at least immune from passive ones. Why HTTP is still not immune to passive attacks? – cnst Jun 29 '14 at 17:10
  • 1
    @cnst: Mail is open for sniffing and manipulating if you don't use PGP or S/MIME. I.e. the price of not correctly using one PKI for TLS is that you have to use another PKI for PGP or S/MIME. If you want to replicate this for HTTP just do your bad certificate checking but don't forget to build a proper PKI layer on top of it, i.e. reinvent the wheel. Of course, if you don't care if you mails get sniffed you might also not care if your HTTP gets sniffed, in which case you could use simple HTTP without SSL. – Steffen Ullrich Jun 29 '14 at 19:38
  • 1
    You keep talking about all these theoretical things which, as I've outlined in my question, and which you did not attempt to refute, don't actually happen in practice all that often. So, no, I don't use any PKI, yet none of my email exchanges with other similarly situated parties gets sniffed (since it's all encrypted, so, passive sniffing is useless), yet all my http traffic is available to the authorities. We don't need no PKI. I do care about privacy, but I also care about freedom more than I care about privacy, and depending on the Certificate Authority cartel isn't what I call freedom. – cnst Jun 29 '14 at 19:52
  • 1
    @cnst: As long it is easy to sniff plain traffic there is no need to deal with encrypted traffic. But if you move to encryption without verifying the endpoint the attacker will move too - these attacks are not theoretical but easy to do if you control the network (e.g. inside public WLANs, your ISP can do it and of course the government). Also, I don't know how you can be sure that nobody is sniffing your data if you don't have full control which peers exchange your data. Like I said, you don't need the cartel you talk about, but you need some way to make sure you talk to the right peer. – Steffen Ullrich Jun 29 '14 at 22:35
  • 2
    So, let them move — not every attacker is capable of moving, say, western governments want to avoid detection. Even though we all know that we are *probably* being mass-surveilled, I'm pretty sure that an active first-hand confirmation of such mass-surveillance would still come as a shock to many. Basically, in your whole viewpoint, you disregard STARTTLS in SMTP as being one bit useful, and also disregard RFC 7258 with it, too. Your ideas might be the majority in this profit-driven world, but my non-profit freedom viewpoint is luckily not alone: https://news.ycombinator.com/item?id=7963228 – cnst Jun 30 '14 at 15:18
  • 1
    I don't think that you argue any longer on a technical level, so it makes no sense to continue the discussion here. – Steffen Ullrich Jun 30 '14 at 15:32
5

Currently, we only have two protocols specified: plain HTTP, and HTTPS which requires valid certificates. If we simply said "HTTPS is now possible with self-signed certificates", your browser could not distingush whether a site you are trying to visit has a self-signed cert because it is supposed to, or because you are being attacked. Thus, it would decrease security.

We could define a new URL scheme, e.g. httpe, where selfsigned certificates are expected. Would require all browsers to implement it before being useful.

Using HTTPS only as a guideline, and simply not showing the padlock icon if selfsigned certs are encountered, would be extremely dangerous: Imagine your web application sends confidential data to a https URL - you do not want those requests to go through if a secure connection cannot be established. Thus, even if we wanted to, moving away from https = both encrypted and authenticated would not work.

We could also ask HTTP servers before the actual request if they support opportunistic encryption, and if they say that they do, upgrade to TLS while still showing HTTP URLs. Something like that is actually being proposed for HTTP 2 here and here.

On a side note, StartSSL offers free certificates for non-commercial/non-sensitive use (this restriction is hidden in their policy, section 3.1.2.1).

Community
  • 1
Jan Schejbal
  • 617
  • 4
  • 4
  • 1
    Your `httpe` suggestion is misguided, because, just like the `https` scheme, it suffer from lack of backwards compatibility, so, I would never adopt anything like that. But thank you very much for finding the IETF drafts, for exactly the things I'm looking for! Glad we aren't left alone, after all, and someone's already working on these improvements for avoiding passive surveillance without having to deal with the certificate cartels! – cnst Jun 29 '14 at 20:00
  • I've created a follow up question based on your mention of the IETF drafts for opportunistic encryption in HTTP -- http://security.stackexchange.com/questions/62094/how-can-i-enable-opportunistic-encryption-for-my-web-site. – cnst Jun 30 '14 at 01:23
3

Agree with @SteffenUllrich that on its own there are few threat models this actually protects against. Virtually all situations you can passively sniff can also be actively sniffed should untrusted HTTPS be used. Using this scheme with something like Moxie Marlinspikes convergence ( www.convergence.io ) would be effective, incidentally, which tries to replace the current CA model with something more robust. That would make me feel more comfortable, though I believe that has its own flaws (those flaws are dwarfed by those of the current CA infrastructure which is for the most part completely insufficient).

And to answer your question, self signed is BETTER than plain HTTP, but the security gains are actually very small because theres no way to verify the identity of the server the client is connecting to.

thomasb
  • 351
  • 2
  • 8
user2867314
  • 610
  • 3
  • 12
  • Sorry, nobody had mentioned convergence when I began writing the answer - before getting distracted. Florian Bidabe got there considerably faster. – user2867314 Jun 30 '14 at 09:16
  • The fact that self-signed HTTPS is worse than plain HTTP was an observation, not a question. Your hypothesis that it is better is not supported by the user experience of the existing implementations. – cnst Jun 30 '14 at 15:10
  • 1
    @cnst I know that this question is quite redundant now; but in that case I would say your observation is incorrect(/ly reflected by the user experience) Self signed HTTPS is more secure than HTTP, even if only marginally. However if the certificate fails to validate and no warning is presented then users would be presented with a false sense of security as we are taught to rely on "the lock icon and https:// in the url bar". Also orginally https was implemented when something _needed_ encrypting, so sensitive information was being passed by implication. – user2867314 Jul 01 '14 at 09:27
  • I'm not sure what you meant to say, but I fail to see how my observation is incorrect. The user experience with self-signed certificates is incorrect. Luckily, it looks like IETF is finally taking some interest in this problem, as per http://tools.ietf.org/html/rfc7258 and http://security.stackexchange.com/questions/62094/how-can-i-enable-opportunistic-encryption-for-my-web-site?lq=1 – cnst Jul 01 '14 at 15:29
  • 1
    @cnst I'm saying your observation is incorrect or is incorrectly reflected in the user experience. BUT if https is in use it implies you have something to "hide". And also, while we are in the realms of "not sure what you are trying to say": your (primary) question was: Why self-signed https is less trustworthy than unencrypted http? My answer was it isn't. Perhaps you should rephrase that to "Why is unsigned HTTPS _perceived_ as less trustworthy than HTTP? in which case my comment stands. – user2867314 Jul 01 '14 at 16:00
2

This is your statement, IMO self-signed or CA expired signed certificates are still trustworthy than none (HTTP).

Security protocol the most secure to the least: 1. HSTS 2. HTTPS 3. HTTP

Who signed your certificate isn't related to how secure is it ? It all depends on who can decrypt it.

Encryption is defined by authentication, non-repudiation, integrity, and confidentiality.

A self signed certificate can be created by anyone, which does not guarantee non-repudiation (can be a fake identity).

In theory this is then less trustworthy than a signed certificate. CA certificates (signed) are more secure in theory, but can quite easily be circumvented: c.f. SSLStrip or SSLSnif http://www.thoughtcrime.org/software/sslsniff/

HTTP(S) is a stateless protocol, you can manipulate POST, GET, PUT frames and also craft cookies. HTTPS offers encryption while HTTP does not, when it comes to carry critical information regardless of the certificate (CA signed, expired, self signed) is still preferable than no encryption at all.

Here's an alternative you may be interested in: http://convergence.io/

Florian Bidabé
  • 703
  • 4
  • 10