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?

Improve this question
1

3 Answers 3

Reset to default
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.

Improve this answer
10
  • 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, 2014 at 2:44
  • 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, 2014 at 6:13
  • 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, 2014 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, 2014 at 19:52
  • 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: news.ycombinator.com/item?id=7963228
    – cnst
    Jun 30, 2014 at 15:18
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).

Improve this answer
2
  • 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, 2014 at 20:00
  • I've created a follow up question based on your mention of the IETF drafts for opportunistic encryption in HTTP -- security.stackexchange.com/questions/62094/….
    – cnst
    Jun 30, 2014 at 1: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.

Improve this answer
5
  • Sorry, nobody had mentioned convergence when I began writing the answer - before getting distracted. Florian Bidabe got there considerably faster.
    – user2867314
    Jun 30, 2014 at 9: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, 2014 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 1, 2014 at 9: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 tools.ietf.org/html/rfc7258 and security.stackexchange.com/questions/62094/…
    – cnst
    Jul 1, 2014 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 1, 2014 at 16:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .