HTTP 2.0 May Be SSL-Only

An anonymous reader writes "In an email to the HTTP working group, Mark Nottingham laid out the three top proposals about how HTTP 2.0 will handle encryption. The frontrunner right now is this: 'HTTP/2 to only be used with https:// URIs on the "open" Internet. http:// URIs would continue to use HTTP/1.' This isn't set in stone yet, but Nottingham said they will 'discuss formalising this with suitable requirements to encourage interoperability.' There appears to be support from browser vendors; he says they have been 'among those most strongly advocating more use of encryption.' The big goal here is to increase the use of encryption on the open web. One big point in favor of this plan is that if it doesn't work well (i.e., if adoption is poor), then they can add support for opportunistic encryption later. Going from opportunistic to mandatory encryption would be a much harder task. Nottingham adds, 'To be clear — we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case — browsing the open Web — you'll need to use https:// URIs and if you want to use the newest version of HTTP.'"

Comments

Only if I can use self signed certs

[Anonymous Coward]

otherwise this sounds like extortion from CAs

Re:Only if I can use self signed certs

[geekboybt]

In the similar thread on Reddit, someone mentioned RFC 6698, which uses DNS (with DNSSEC) to validate certificates, rather than CAs. If we could make both of them a requirement, that'd fit the bill and get rid of the extortion.

Re:Only if I can use self signed certs

[Anonymous Coward]

Downside with self signed certs is that you get that pop up warning about trusting the cert. For HTTP 2.0 to take off and require SSL (which is a good idea) there needs to be cheap access to valid certificates. Right now, the most reputable SSL vendors are way too expensive.

Re:Only if I can use self signed certs

[GameboyRMH]

This. If so, it will be a MASSIVE improvement.

A connection with a self-signed cert is, in a very-worst-case and highly unlikely scenario, only as insecure as the plaintext HTTP connections we use every day without batting an eye. Let's start treating them that way.

SSL-only would be a great first step in making life miserable for those NSA peeping toms.

Re:Only if I can use self signed certs

[Anonymous Coward]

The obvious argument (and I'm not saying it's a valid one) is that self-signed certs de-legitimize certification (e.g., anyone can sign one and there's no proof that "anyone" is trustworthy, which makes HTTPS meaningless).

Re:Only if I can use self signed certs

[girlintraining]

otherwise this sounds like extortion from CAs

You are so close. Eliminating plain-http would destroy the internet as we know it because the only alternative then is forking cash over to an easily-manipulated corporation for the priviledge of then being able to talk on the internet. It's an attack on it's very soul.

It would kill things like Tor and hidden services. It would oblitherate people being able to run their own servers off their own internet connection. It would irrevocably place free speech on the web at the mercy of corporations and governments.

Re:Only if I can use self signed certs

[CastrTroy]

Only if the standard is actually used. Look how long it's taking IPV6 to get implemented. And there's a very real reason why we need to upgrade. I'm definitely not holding my breath until HTTP 2.0 get significant usage.

Re:Only if I can use self signed certs

[i kan reed]

To be fair, no one is telling you to run your server on http 2.0. You can still run a gopher or ftp server, if the outdated technologies appeal to you enough.

(Please don't dog pile me for saying ftp is outdated, I know you're old and cranky, you don't have to alert me)

Re:Only if I can use self signed certs

[bunratty]

The problem with self-signed certs is that there isn't a good way to determine whether a site is legitimately using a self-signed cert, or if an attacker is successfully accomplishing a man-in-the-middle attack using a self-signed cert. If I use HTTPS, I want an assurance of security, and if there's a possible MITM attack in progress, I surely want to know immediately.

Re:Only if I can use self signed certs

[Anonymous Coward]

I think that's what the OP is suggesting, actually. Turn off the self-signed cert warning.

That's really the only thing stopping me from putting HTTPS stuff on my server, it's annoying as hell to have to keep clicking through that warning every time I start a new browser session. HTTPS seems to have been designed around the assumption that "who the server claims to be" is vastly more important than "the server is encrypting this data", which is not necessarily true nowadays.

Re:Only if I can use self signed certs

[Alain Williams]

Validating the certificate is the problem. If it can't be validated then SSL is useless, it is open to a man in the middle attack. The trouble with the current SSL system is that even a certifcate signed by a CA is spoofable; an CA can sign a certificate for any domain, so if you can twist arms stronly enough (think: NSA or well funded crooks) then you can still do a MitM attack. So: the first thing that is needed is a robust way of validating certificates -- I don't know how that could be done.

The other problem with SSL everywere is that multiple virtual hosts on the same IP address would break on a large number of current machines. There is the SNI mechanism that allows that but it is not supported by IE on MS XP (& others), so we cannot use SNI until MS XP use is insignificant -- which will be a few years away, even is MS does declare it dead.

Re:Only if I can use self signed certs

[girlintraining]

To be fair, no one is telling you to run your server on http 2.0.

The same can be said whenever a new version of a protocol comes out. But invariably, people adopt the new one, and eventually nobody wants to support the old one... and so while nobody is "telling you" anything... eventually you just can't do it anymore because all protocols depend on the same thing.. people using them. If nobody's serving content on them, then nobody's supporting the ability to read that content either.

(Please don't dog pile me for saying ftp is outdated, I know you're old and cranky, you don't have to alert me)

I am neither old, nor cranky. I am however an experienced IT professional who's been here since the beginning. And experience is more valuable that book smarts or version numbers. Knowledge is what tells you how to bring the dinosaurs back... Wisdom is knowing why that's a bad idea.

Re:Only if I can use self signed certs

[GameboyRMH]

Well just as now, you should make sure the site uses a trusted cert (through a CA or otherwise) before sending sensitive info. You don't send important logins or credit card info over plain HTTP now do you?

Re:Only if I can use self signed certs

[Anonymous Coward]

There's an upcoming encryption project the "Fenrir" project that will do this, among a shit load of other things. It will be presented in a lightning talk @CCC in europe at the end of december. It's not yet finished, but keep it in mind the name :)

Re:Only if I can use self signed certs

[i kan reed]

Wisdom is knowing that Jurassic Park is fiction, and that we contain wild animals in zoos all the time just fine

Re:Only if I can use self signed certs

[0123456]

Yeah, because who cares that removing that warning allows anyone to pretend to be your bank?

Re:Only if I can use self signed certs

[Anonymous Coward]

That's pretty cool. And really more or less the way it should've been done in the first place.

Except for this nagging problem that DNS, and DNSsec, is still hierarchical and thus we still have single points of extortion, with as ultimate root... the US government. That is not going to sit well with the 95% of the world that is nominally not under US jurisdiction. Even besides that, there are fewer TLD wranglers than there are certificate sellers.

So a better solution to that is needed before that idea will be viable. And no, neither the UN nor the ITU (now also UN, so same thing) nor any other already existing thing is going to be good enough for this. No political body is, unless it is really indepentend and can talk to the rest as an equal. That, or figure out a way to have trustable certificates and not be dependent on some cabal of key wranglers, be it random CA-exploiting companies or be it the not-so-randomly* chosen managers of root domains.

* Why didn't DENIC get to run .net? They had an objectively better case. ICANN needed to break its own rules to give it back to verisign anyway. Verisign also sells certificates, by the by.

Re:Only if I can use self signed certs

[Anonymous Coward]

I'm who I say I am. You can trust me.

Re:Only if I can use self signed certs

[Anonymous Coward]

We can still differentiate between certificates that are verified and those that are self-signed. It would just be nice to be able to have some level of encryption instead of no encryption. The browser would only indicate a site was secure if the certificate was signed by a reputable certificate authority.

Re:Only if I can use self signed certs

[bsdasym]

I'd sign up for your newsletter if the connection was identified differently. Allow self-signed certs by default, but change the browser security 'color' thing from blue/green to yellow -- or even red if there is no non-encrypted traffic allowed.

CA certificate signing does serve a valuable function, one that is entirely defeated if there is no indication that a cert is self signed.

Re:Only if I can use self signed certs

[Anonymous Coward]

My predictions:
- TLS will be required. No bullshit, no compromise, no whining. On by default, no turning it off.
- RFC6698 DNSSEC/DANE (or similar) certificate pinning support required.
- DANE (or similar) to authenticate the TLS endpoint hostname via DNSSEC - that is the MITM defense, not a CA
- CA not required - if present, authenticates ownership of the domain, but not whether there's an MITM

We have a shot at a potentially clearer hierarchy with DNSSEC than we do with CAs, where it's anything-goes, anyone can sign anything - and to state-sponsored attackers, clearly have, and do (whether they know it or not). We might need to fix DNSSEC a bit first, along the lines of TLS 1.3 (see below).

Also, TLS 1.3 ideas are being thrown around. It will be considerably revised (might even end up being TLS 2.0, if not in version number then at least in intent). Here are my predictions based on what's currently being plotted:
- Handshake changed, possibly for one with less round-trips/bullshit
- Cipher suites separated into an authentication/key exchange technique and an authenticated encryption technique (rather than the unique combination of the two)
- Renegotiation might not stay in or redesigned?
- Channel multiplexing?
- MD5, SHA-1, and hopefully also SHA-2 removed, replaced with SHA-3 finalists: Skein-512-512? Keccak-512 (as in final competition round 3 winner, but hopefully NOT as specified in the weakened SHA-3 draft)?
- Curve25519 / Ed25519 (and possibly also Curve3617) for key exchange and authentication: replace NIST curves with safecurves
- RSA still available (some, such as Schneier, are wary of ECC techniques as NSA have a head start thanks to Certicom involvement and almost definitely know at least one cryptanalysis result we don't), but hardened - blinding mandated, minimum key size changed (2048 bit? 3072 bit? 4096 bit?)
- PFS required; all non-PFS key exchanges removed; Curve25519 provides very very fast PFS, there's very little/no excuse to not have it
- All known or believed insecure cipher suites removed. (Not merely deprecated; completely removed and unavailable.)
- Most definitely RC4 gone, beyond a doubt, that's 100% toast. There may be strong pushes for client support for RC4-SHA/RC4-MD5 to be disabled THIS YEAR in security patches if at all possible! It is DEFINITELY broken in the wild! (This is probably BULLRUN)
- Possibly some more stream cipher suites to replace it; notably ChaCha20_Poly1305 (this is live in TLS 1.2 on Google with Adam Langley's draft and in Chrome 33 right now and will more than likely replace RC4 in TLS 1.2 as an emergency patch)
- AES-CBC either removed or completely redesigned with true-random IVs but using a stronger authenticator
- Probably counter-based modes replacing CBC modes (CCM? GCM? Other? Later, output of CAESAR competition?)
- The NPN->ALPN movement has pretty much done a complete 180 flip. We will likely revert to NPN, or a new variant similar to NPN, because any plaintext metadata should be avoided where possible, and eliminated entirely where practical - ALPN is a backwards step. IE11 supports it in the wild right now, but that can always be security-patched (and it WILL be a security patch).

Of course, discussions are ongoing. This is only my impression of what would be good ideas, and what I have already seen suggested and discussed, and where I think the discussions are going to end up - but a lot of people have their own shopping lists, and we're a long way from consensus - we need to bash this one out pretty thoroughly.

Last week's technical plenary was a tremendous kick up the ass (thanks Bruce! - honestly, FERRETCANNON... someone there reads Sluggy Freelance...). We all knew something had to be done. Now we're scratching our heads to figure out what we CAN do; as soon as we've done that, we'll be rolling our sleeves up to actually DO it. After consensus is achieved, and when the standard is finished, we'll be pushing very, very strongly to get it deployed forthwith - delays for compatibility because of client bugs will not be an acceptable excuse.

Re:Only if I can use self signed certs

[DuckDodgers]

Signed Certificate + TLS = you have an encrypted connection with the entity named on the certificate.

Unsigned Certificate + TLS = you have an encrypted connection with someone, and you can't know who unless you independently verify the certificate signature. (e.g. My brother sets up a site with a self-signed certificate, and then calls me on the phone and tells me the certificate signature. When I access his site, I view the certificate and make sure the signature matches.)

Re:Only if I can use self signed certs

[denis-The-menace]

My predictions:
It don't matter. The NSA will simply require the root certs of all CAs and make all this work moot.

Re:Only if I can use self signed certs

[Anonymous Coward]

We do not want to fragment the internet, but this enormous subversion of trust already threatens it. Last week's technical plenary's hums clearly (overwhelmingly, even unanimously) agreed that what is happening - massive, state-sponsored surveillance - is an attack on the Internet as a whole. Clearly the US government (not the only attacker, but the biggest) appointing IANA is a conflict of interest. That is not even a point of debate anymore.

Bruce actually openly pointed this out during the prior talk: "...we're going to need to figure something out, or it's going to be the ITU".

The room laughed. The ITU is clearly unsuitable, but it does probably need to be a .INT, at least, for the root itself - maybe also for .COM and .NET? The idea of a completely new treaty (IANA.INT?) has been floated and is probably the best solution for everyone, although in practice, it's hard to say what will actually happen - we are engineers, not politicians!

Re:Only if I can use self signed certs

[SteveTheNewbie]

So why not setup your own CA, install the CA into your computer/device and then use that to sign your certs.

Voilà, no more popup warnings.

Re:Only if I can use self signed certs

[0123456]

The browser would only indicate a site was secure if the certificate was signed by a reputable certificate authority.

How many people do you think check their web browser claims the site is secure before entering their login details?

Removing warnings about self-signed certificates just gives a new way for users to do stupid things without thinking about it.

Re:Only if I can use self signed certs

[Jason Levine]

In theory, yes. If tomorrow Chrome, Safari, IE, FireFox, etc all upgraded their browsers to require HTTP 2.0/HTTPS-Only, tons of websites would be faced with the prospect of paying hundreds of dollars for a SSL certificate. These hobby sites with no actual income wouldn't be able to afford it. Presently, to host a website I can pay for a $10 a month shared hosting plan and $15 a year for a domain name. (My registrar is a bit more expensive but I've had a lot of good experience with them so I'm not likely to flee to save $5 a year.) This means I can run a site for $135 a year. (Yes, if it becomes even remotely popular, I'll need to ditch the shared hosting for dedicated but let's assume this is a small-time site to start with.) If you add in an SSL certificate requirement, you're adding in about $149 more every year (based on GeoTrust pricing - other CAs might be more or less). That's doubling the cost.

In practice, of course, you'll get an IP6 type of situation. Tons of sites will cling to the old version (HTTP 1.0/HTTPS-Optional) and the browsers will need to support this. Any browser that makes HTTP 2.0/HTTPS-Only a requirement will be committing marketshare suicide. (Side note: Is it bad if I'm hoping IE does this?) So while the "official spec" will say that all websites should go HTTPS-Only, people will ignore this and keep on the old spec until either HTTP 3 comes out (which goes back to HTTPS-Optional) or until the SSL situation is sorted out to bring the price radically down.

Re:Only if I can use self signed certs

[Anonymous Coward]

If you want to know if there is a MITM attack, then https with current browsers is the wrong tool. Browsers silently accept a server switching certificates on the fly, as long as they are signed by some CA it knows. Hell, even if you add an explicit certificate for a specific cite, it will give you no warning or hint at all if one page return is signed with a chinese CA instead.
(And have the "thrustworthy" western CAs now finally stopped issuing catch-all-subCAs? 5 years ago all they wanted for one of those was $500 and a long text in which you promise to only use it internally (as your for example want to have a transparent malware scanning proxy in your organisation)).

Re:Only if I can use self signed certs

[Anonymous Coward]

Exactly

HTTP 1.1: go anywhere, not hounded by SSL Certificate chain of trust checks
HTTP 2.0: Every damn site goes "oh noes, this may be an attack site"

What I propose, half-heartedly is to trust self-signed implicitly but only at the highest encryption level. If we can do this with regular SSH, then I don't see why we can't do this with SSL. What we want is to prevent Snooping and MITM. There still must be a way to determine if www.bankofamerica.isevil.cn and www.bankofamerica.com are in fact different sites and not to trust the former. The most direct way is by leveraging DNS to check a machine fingerprint. eg When the client looks up the ip address it acquires the IP4, IP6 and a Self-Signed Certificate Fingerprint, whereby the fingerprint basically says "This is what it should be, don't trust the self-signed certificate otherwise"

Re:Only if I can use self signed certs

[Anonymous Coward]

You can create your own cert. It maybe give warnings about security or whatever but its still usable. I've done this on a few demo sites where we did not see the point in paying for a legitimate one.

Re:Only if I can use self signed certs

[Anonymous Coward]

Removing warnings about self-signed certificates just gives a new way for users to do stupid things without thinking about it.

But training your users* to ignore those warnings just to access your site with encryption does the same thing. Same with telling your users to install a new CA file to their browser so your self-signed cert doesn't show popups without you having to regularly contribute to the current CA racket.

What we're trying to get at is a system where the encryption portion is separate from the authentication portion. There's no reason the two need to be one in the same on the modern internet.

*: Assuming "your users" are the internet at-large, not some 15-user uber-l33t tech discussion forum site where they've all already tweaked their browsers to remove those warnings anyway.

Re:Only if I can use self signed certs

[GoogleShill]

Having access to root CA private keys doesn't help the NSA much if PFS is employed.

Re:Only if I can use self signed certs

[i kan reed]

You're a well-known poster? Well excuse me. I didn't know.

But Jurassic Park was the natural thing to reply to, because it seemed intuitively and naturally related to your argument.(And I think an actual dinosaur zoo would be awesome).

Re:Only if I can use self signed certs

[GoogleShill]

That's really the only thing stopping me from putting HTTPS stuff on my server, it's annoying as hell to have to keep clicking through that warning every time I start a new browser session.

Did you know that you can manually trust the certificate and avoid that dialog every time you visit your site?

Re:Only if I can use self signed certs

[metrix007]

Use StartSSL or install the self signed cert into your browsers. Easy peasy.

Re:Only if I can use self signed certs

[Anonymous Coward]

If we use DNSSEC to pin a chain of trust all the way to the root, we have, hopefully, authenticated that certificate to its hostname. That, alone, mitigates an MITM, and it is even within scope of the DNS hierarchy

Contrast: CAs have a flat, global authenticative fiat - therefore, they are fundamentally less secure, as instead of multiplying with the depth of hierarchy, the potential weaknesses multiply with the number of commonly-accepted CAs.

Of course, you can then (optionally) also choose to use a CA to countersign your certificate in a chain, if you want; presumably you pay them to certify who owns the domain.

In the event of any disagreement, you just detected (and therefore prevented) an active, real MITM attack. An attacker would have to subvert not just a random CA, but hierarchically the correct DNS registry and/or registrar -and- a CA used to countersign, if present. We can make that a harder problem for them. It increases the cost. We like solutions that make a panopticon of surveillance harder - anything that makes it more expensive is good, because hopefully we can make it prohibitively expensive again, or at least, noisy enough to be globally detectable.

There's also the separate question of the US Government holding the DNS root. Someone has to. Obviously it can't be them anymore. Even if we saw it, we can no longer trust it.

We are also welcome to potential more distributed solutions. If you happen to have a really nice, secure protocol for a distributed namespace (although please something that works better than, say, NameCoin), please publish.

Re:Only if I can use self signed certs

[Kjella]

Except for this nagging problem that DNS, and DNSsec, is still hierarchical and thus we still have single points of extortion, with as ultimate root... the US government.

The DNS system by nature has a single root, the trust chain doesn't necessarily have that. You could for example require that all TLDs be signed with the keys of the five permanent members of the UN security council and require all of them to be present. So Canada would own the keys to the ".ca" domain and they would be signed by the US, Russia, China, UK and France. Canada gets to do whatever they want under their domain and nobody can spoof them unless they a) steal Canada's private keys or b) steal all the other five private keys. Of course the tin foil hat brigade don't trust any authority and that's fine, you can always check the fingerprint. But I don't see how it hurts your security to have the ".com" server certifying that you own "yourdomain.com" versus a totally self-signed certificate with yourself as CA. At worst it's no trust vs no trust.

As for being "blackmailed", well if they're being nasty they're already holding all your traffic hostage (except direct IP access). The base certificate "owner of yourdomain.com" should be free with the DNS service, if you want something to actually certify who you are that's different. Really it's nothing more than the service they're doing already with DNS and DNSSEC, making sure that they're pointing you to the right server.

Re:Only if I can use self signed certs

[james_shoemaker]

You can buy a properly signed SSL cert for as little as $9/year (possibly lower), if that is too much then self signed is always available.

James

Re:Only if I can use self signed certs

[GoogleShill]

Switching certificates, even to one with a different CA doesn't change anything at all with respect to security, assuming equal key strengths. In your hypothetical scenario, the attacker would have had to possess a valid certificate from a CA that you already trusted. That certificate could have been used during the initial handshake as well as during a certificate-switch.

The problem is that your browser trusted a non-trustworthy CA.

Re:Only if I can use self signed certs

[0123456]

The problem is that your browser trusted a non-trustworthy CA.

The problem is a lack of trustworth CAs in a world where governments want to spy on everyone.

Re:Only if I can use self signed certs

[0123456]

But training your users* to ignore those warnings just to access your site with encryption does the same thing.

No, it doesn't, because they'll do that for fluffykittens.com, but they won't do it for their bank.

Re: Only if I can use self signed certs

[Anonymous Coward]

If you can use self signed cert, then cert is useless.

Re:Only if I can use self signed certs

[spitzak]

You can check if the certificate is the same one the site produced last time.

Or go through a third party that confirms it is seeing the same certificate you are seeing.

Obviously not foolproof but these both approach the current security of the authority-signing.

Re:Only if I can use self signed certs

[spitzak]

Check if it is the same certificate you saw when you visited the site the last time.

Go through a third party (perhaps one using a signed certificate) and check that you both see the same certificate.

Both of these will defeat a lot of man-in-the-middle attacks.

Re:Only if I can use self signed certs

[Anonymous Coward]

It doesn't matter how trustworthy the CA's are. The NSA possesses the private key of at least one trusted CA and can invisibly spoof any HTTPS site on earth. Numerous other governments are sure to be able to do the same. Hell, if I were them, I'd be running a trusted CA as part of performing my function.

The biggest obstacle for the governments is that they will have to physically intercept traffic between you and the real server. That's only convenient to do routinely when your client or the server is under their jurisdiction.

Re:Only if I can use self signed certs

[Shakrai]

Wisdom is knowing that Jurassic Park is fiction, and that we contain wild animals in zoos all the time just fine

That's because Wayne Knight doesn't have any financial incentive to shut down the security fences keeping the gray wolves secure at your local zoo. ;)

Re:Only if I can use self signed certs

[Anonymous Coward]

Go shove a fucking dick up your ass you goddamned adolescent piece of shit

Re:Only if I can use self signed certs

[AmiMoJo]

HTTP 2.0 will take off because it offers the site operator something valuable - better efficiency. Less bandwidth per user, faster loading times, more users per server etc. IPv6 offers them basically nothing other than cost to support a tiny minority of users, where as HTTP 2.0 will be transparently supported by every major browser and bring real improvements. Not sure about deployment cost but on many web servers it will probably be near zero cost.

Re:Only if I can use self signed certs

[Bill, Shooter of Bul]

Well, except when the escape :

http://content.time.com/time/specials/packages/completelist/0,29569,2041628,00.html

Panda's tend to not eat people.

Re:Only if I can use self signed certs

[Anonymous Coward]

Sheesh, get some humor training while your at it. Not everything is an attack on you, and you're not that important.

Re:Only if I can use self signed certs

[Anonymous Coward]

No, it was a logical inference that you were talking about the best know story of bring dinosaurs back, not a straw man.

Re:Only if I can use self signed certs

[Bill, Shooter of Bul]

Yeah, good luck with that argument. Won't be long before you have a ton of crazy people claiming the $9 represents an extreme hardship on their eCommerce site.

Re:Only if I can use self signed certs

[GoogleShill]

Agreed. I was simply pointing out that switching certificates is a non-issue.

Re:Only if I can use self signed certs

[savuporo]

Or you could go Convergence and use a distributed, agile trust model.

Re:Only if I can use self signed certs

[ultranova]

It don't matter. The NSA will simply require the root certs of all CAs and make all this work moot.

Actually, it would still help. There's a huge difference in resource requirements between listening in on a connection and doing a MITM for it. Mass surveillance is only possible because modern technology makes it cheap; every speedbumb, no matter how trivial, helps when it applies to every single connection.

Re:Only if I can use self signed certs

[SpaceLifeForm]

Agreed. This is a bad idea. There is no reason to continue on the path of TLS which is already suspect in terms of security.

Re:Only if I can use self signed certs

[petermgreen]

The problem with that argument is that it assumes that passive monitoring of unencrypted data and MITM of encrypted connections have equal cost to the attacker. In practice passive listening has essentially zero risk of getting caught and low CPU cost (just the cost of running whatever filter the attacker wants to try and pull out interesting information). MITM has significant CPU cost and significant chance of getting caught (since the attacker does not know if you are verifying the certificates or not).

Re:Only if I can use self signed certs

[broken_chaos]

- MD5, SHA-1, and hopefully also SHA-2 removed, replaced with SHA-3 finalists: Skein-512-512? Keccak-512 (as in final competition round 3 winner, but hopefully NOT as specified in the weakened SHA-3 draft)?

The SHA-2 family are still unbroken, and I don't believe there are even any substantial weaknesses known. No reason to drop support for them at all.

Re:Only if I can use self signed certs

[Anonymous Coward]

>Panda's tend to not eat people.

Perhaps they're just super efficient and leave no trace?

Re:Only if I can use self signed certs

[petermgreen]

The cert itself is not actually the biggest problem with https for the little guy. I'm aware of at least one CA that is recognised by major browsers and hands out basic certs for free and many others that hand them out for far less than the price you give.

The bigger issue is IPs. Right now webhosts are practically limited* to one cert per IP and that means you need a dedicated IP which your hosting provider will almost certainly charge you extra for (partly because it increases their costs slightly, partly because they can)

* Hopefully in a few years time this will no longer be the case as browser/os combinations that don't support SNI die off.

Re:Only if I can use self signed certs

[ultranova]

Eliminating plain-http would destroy the internet as we know it because the only alternative then is forking cash over to an easily-manipulated corporation for the priviledge of then being able to talk on the internet.

Well, the simplest way to combat this would be to device a new URI scheme that combines both a DNS/IP adress and a public key. That way lose the need to have external certification authorities, at the cost of also losing easy memorization of adresses. But who types them in by hand anyway?

It would kill things like Tor and hidden services.

Tor would be completely unaffected. Simply have the project create a dummy root certificate, publish it, then have people add it to the browser they use to browse Tor (Tor Browser Bundle would naturally come preconfigured).

Re:Only if I can use self signed certs

[CBravo]

Certificates change because they expire, too.

Re:Only if I can use self signed certs

[bunratty]

Exactly. That's why there's a warning when you go to an HTTPS site and it gives you a self-signed certificate, and why it would be a mistake to remove the warning.

Re:Only if I can use self signed certs

[ultranova]

The problem with self-signed certs is that there isn't a good way to determine whether a site is legitimately using a self-signed cert, or if an attacker is successfully accomplishing a man-in-the-middle attack using a self-signed cert.

Well, you need to trust you got the right URL anyway, so the most logical way would be to embed the certificate fingerprint into it. Something like httpc://abcdef01020304/slashdot.org. This won't stop malicious agents from spreading false URLs, but nothing's stopping them from doing so with any certificate system.

Re:Only if I can use self signed certs

[turbidostato]

"That's really the only thing stopping me from putting HTTPS stuff on my server, it's annoying as hell to have to keep clicking through that warning every time I start a new browser session."

I find annoying your ignorance.

"HTTPS seems to have been designed around the assumption that "who the server claims to be" is vastly more important than "the server is encrypting this data", which is not necessarily true nowadays."

So would you really prefer sending your bank details cyphered to a criminal than in the clear to your bank? Weird.

Re:Only if I can use self signed certs

[Bill, Shooter of Bul]

Well, come to think of it, I've never met a panda that didn't lust for human flesh.

Re:Only if I can use self signed certs

[Lennie]

HTTP/2.0 is garanteed to be defined in the RFC as SSL-only, because proxies on the public internet just won't understand the completely protocol.

The real question is, will HTTP/2.0 with non-verified certs be allowed for http:/// URL's.

Re:Only if I can use self signed certs

[Lennie]

http is just a transport, port 80 (http) is the the only port that is actually open on most networks, the next pupulair is 443 (https).

the transport is supported by the browser, I'm pretty sure it will remain supported for a very, very long time.

especially if handling certificates remains to suck as bad as it does now the group of people that will deploy
HTTP/2.0 will remain some what small.

DNSSEC/DANE is the only alternative, which isn't supported by any browser by default right now.

Most operating systems don't even support it, which would be the most elegant want to support DNSSEC from the browser.

Not everyone is convinced DNSSEC is a solution, but somewhere in between both camps, probably closer to, deploying DNSSEC is a good thing:
we already depend on DNS, your DNS-provider, the registrar, the registry and the root. We are just securing DNS.

If you don't want to use a CA: DNS is what points you to your self-signed certificate server. Might as well make sure it is the right self-signed certs with signed-DNS.

If you want more, CA-signed certs or even CA-signed EV-certs can still be used with DNSSEC. It actually more secure because you can specify which certs the browser should expect or which CAs are allowed to sign it. Remember that 1000s of CA-problem ? DNSSEC solves that.

Re:Only if I can use self signed certs

[Lennie]

That is why I think DNSSEC might be a good idea afterall, you already depend on DNS for your domainname. with DANE you can restrict the certs that your browser will accept (by 1 or multiple CAs or by 1 or more fingerprints, thus certs).

Re:Only if I can use self signed certs

[Jason Levine]

If you don't mind me asking, where is an SSL certificate available for $9 a year? I've only ever seen the ~$100 versions. The cheapest I've found is $65 a year from InstantSSL.com. This would still add about 50% onto the cost of a "$10 a month shared hosting/$15 a year domain name" setup.

Re:Only if I can use self signed certs

[Bob Uhl]

The DNS system by nature has a single root, the trust chain doesn't necessarily have that.

The SPKI guys back in the 90s figured this stuff out really, really well. Ideally, one would have: a DNS trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of owns example.net; an IP trust chain indicating that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of the owner of 192.0.2.7, and possibly certifications from other organisations (Better Business Bureau perhaps) that b24e:6f99:2f6f:34d8:9c8a:c6da:daaf:e3bb:002e:2ba4:2622:4cf9:cd8b:14a5:71d8:5a9c:18dc:47a2:9a2d:2951:a26b:26fa:2165:85fc:7006:0d66:1c8e:a4f4:ea36:4d04:57a0:8ae4 speaks on behalf of a decent dude; users' browsers might demand the first two and show more confidence for further certifications.

SPKI's contributions included a k-of-n standard and, more importantly, transitive authorisations. So once I am granted authorisations from .com to use example.com, I can pass that authorisation on to any machines under my control; I can delegate mail.example.com to my mail-handling group without also giving them financials.example.com. I can do the same thing with my IP address space, my bank account information &c. I could add third-party attestations to my identity, perhaps third parties more resistant to rubber-hose persuasion than the standard ones. Pinning might rely on my personal closely-held private key, which is never online at all but which delegates to online (time-limited and/or revocable) keys. Calculating this stuff is very, very simple and fast. There's no need for any fees along the way. It's easy to reason about.

You can see how this might work with internet governance: each organisation would be responsible for the namespace it was assigned, and be easily able to segment that namespace however it wished. Anyone at any level could cross-certify; damage to the trust chains could be contained.

SPKI is, in every way save uptake, superior to XPKI.

Re:Only if I can use self signed certs

[VortexCortex]

Not using HTTP-AUTH proof of knowledge to key your symmetric streams? HTTP implementers are provably insane or malicious. Time to ditch the web, they do not have our best interests at heart.

Re:Only if I can use self signed certs

[Anonymous Coward]

I do..

Re:Only if I can use self signed certs

[guruevi]

You only need a commercial CA cert if you want your identity (somewhat, remotely) confirmed. Encryption != identification, SSL was never meant to be used that way. If you need an identification and trust mechanism, you should probably go through DNS (DNSSEC etc) because DNS is how you resolve people-friendly-names to technical-data. If it were only computers talking to each other, we would've fixed this issue a long time ago (because computers can fairly easily identify the difference between paypal.com.com and paypal.com, heck we would've probably stuck to communication by IP. Since identification issues are PEBKAC we need to resolve this issue at the point we make computers people-friendly

Re:Only if I can use self signed certs

[Anonymous Coward]

Having access to root CA private keys doesn't help the NSA much if PFS is employed.

Yes, it does. Once it has got its hands on root CA private keys, NSA can MITM the transactions where the PFS keys are exchanged, and then it has a clear window to whatever is being communicated. PFS only secures information that has been exchanged before CA private keys were compromised.

Re:Only if I can use self signed certs

[Anonymous Coward]

My prediction:

All browsers will support running HTTP 2.0 over unencrypted TCP because why the hell not. Plenty of people will use HTTP 2.0 unencrypted because for some unexplainable reason Microsoft decided to make that the default setting in their servers.

Re:Only if I can use self signed certs

[Anonymous Coward]

Downside with self signed certs is that you get that pop up warning about trusting the cert.

If everyone has to use it then the pop up-clicking will be something people just do without thinking. This will make browsers remove the pop up and auto-accept them since you don't want to teach people to just click on everything that pops up.

Re:Only if I can use self signed certs

[Anonymous Coward]

So Canada would own the keys to the ".ca" domain and they would be signed by the US, Russia, China, UK and France. Canada gets to do whatever they want under their domain and nobody can spoof them unless they a) steal Canada's private keys or b) steal all the other five private keys.

So basically Canada would be betting their security on France not becoming a member of the surveilance club.

Re:Only if I can use self signed certs

[Jaruzel]

I tried that - then discovered that MS Exchange* will NOT do ActiveSync properly to some devices unless the cert is proper trusted one.

Bloody annoying.

If the world wants https-everywhere, then a) free trusted signed certs must be available for everyone (like StartSSL offers, but with wildcard certs as well), and b) the ability to attach different certs to virtual hosts on the SAME ip must be enabled (IIS on Windows can't do this - can Apache/non-MS-Webservers do it?)

(*And no, I wont swap to a Linux/SendMail/Whatever solution, as I'm a professional MS consultant, so have to eat my own dog food)

-Jar

Re:Only if I can use self signed certs

[Anonymous Coward]

install the self signed cert into your browsers. Easy peasy.

Where can I find a guide that explains to the people visiting my web page how to do that? It shouldn't need to be more than a few lines, if it's actually "easy peasy", and not super hard, like trying to get them to understand that they should enter the URL in the location bar, and not into the Google search field.

Oh, and how do I direct my visitors to this description, if SSL is required? Seems they'd need to follow the guide before they can get to the page where I tell them to follow the guide, and download the certificate.

Re:Only if I can use self signed certs

[heypete]

As an example, NameCheap, an American registrar and host, sells Comodo certs for $9/year. GeoTrust are $10.95/year, while Thawte certs are $40/year. Prices drop by a few dollars for multi-year purchases. Gandi, a French registrar and host, offers Comodo certs for $16/year, again with discounts for multi-year purchases.

StartSSL offers domain-validated certs completely free of cost for non-commercial uses. Commercial users are expected to undergo validation (they validate both the person requesting the certificate as well as the organization) which costs about $100/year but entitles them to issue an infinite number of certificates for systems they control (i.e., no issuing certs for your friends, but issuing certs for your work servers is fine). In short, they charge money for what costs them money: signing a cert is essentially free, while validating identity is expensive.

There's plenty of options for cheap certificates, particularly if you buy from a reseller rather than from the CA itself.

Re:Only if I can use self signed certs

[Terrasque]

You might like this draft then : http://tools.ietf.org/html/draft-nottingham-http2-encryption-01

this document also proposes a "relaxed" profile of HTTP/2.0 over TLS that does not require strong server authentication, specifically for use with "http://" URIs.

Re:Only if I can use self signed certs

[Terrasque]

You've fallen into the trap of seeing security as either black or white. Self signed certs are dark gray enough that for you it's black, and thus the same as unencrypted HTTP. And CA verified cert is light gray enough to be white, and thus secure.

The truth is that self signed is much better than unencrypted, and CA verified - while even better - still have enough problems to drive a truck through. Sideways.

Which is why people are talking about DANE, which is even lighter gray than CA validated, but still far from perfect.

You can't turn security into black and white. It's a scale, with various shades pf gray.

Re:Only if I can use self signed certs

[Anonymous Coward]

What warning? I don't think any browser in the world gives warnings on regular plain unencrypted HTTP, the most insecure protocol of them all.

Re:Only if I can use self signed certs

[Anonymous Coward]

The DNS system by nature has a single root, the trust chain doesn't necessarily have that.

The DNSsec chain does, necessarily, have that. Spoofing is one thing, putting (political) pressure on those below you to have them do your bidding another. Guess which is more likely from the de facto owner of the organisation running the root? Who, of course, already hold all your traffic hostage AND pressure everybody else in working along with them. So this'll just mean that much easier access to keys for them.

Is it still tin foil hattery if the tin foil hat's fears prove to be true?

Re:Only if I can use self signed certs

[GameboyRMH]

And yet if you try to sign in with no cert, which is worse, there's no warning. Slashdot was such a site until recently. Some other forums I'm on still use plaintext logins. So why give the DANGER WILL ROBINSON! warning with a self-signed cert and act like nothing's wrong if there's no cert?

Without some kind of content-aware AI there will be no way to give warnings appropriately. Right now we rely on user knowledge to know when to check for a trusted cert. We'd be doing the same if browsers accepted self-signed certs with no warning. So why not do that?

Re:Only if I can use self signed certs

[Anonymous Coward]

SKEIN 1024/1024!!!! Do it!

Re:Only if I can use self signed certs

[Anonymous Coward]

Why don't you pony up for a free SSL cert? /facepam

The StartSSL Free (Class 1) certificates are domain or email validated and mostly referred to as the free certificates. Because the checks are performed mostly by electronic means, they require only minimal human intervention from our side. The validations are here to make sure, that the subscriber is the owner of the domain name, resp. email account. You may find additional information on this subject in our CA policy.

The StartSSL Free certificates are intended for web sites which require protection of privacy and prevent eavesdropping. However information presented within these certificates, except the domain name and email address, are not verified. Should you need higher validated certification, please check out our StartSSL Verified (Class 2) certificates.

Re:Only if I can use self signed certs

[felipou]

The reason is paranoia. SHA-2 family was designed by the NSA.

Re:Only if I can use self signed certs

[devman]

AES GCM is already in TLS 1.2 and acts as a stream cipher, I'd like to see more AEAD modes in TLS though. The way TLS was using IV's in CBC mode cipher suites has already been fixed.

Re:Only if I can use self signed certs

[Anonymous Coward]

The browser would only indicate a site was secure if the certificate was signed by a reputable certificate authority.

How many people do you think check their web browser claims the site is secure before entering their login details?

Removing warnings about self-signed certificates just gives a new way for users to do stupid things without thinking about it.

Suppose I'm Joe Sixpack, and I don't understand jack about web security, I'm going to enter my password into any site that (A) looks kinda sorta like Facebook and (B) doesn't pop up a big angry red certificate warning with flashing lights and a loud klaxon to tell me I'm being haxxored.

Now suppose you're Mallory the malicious Facebook account phisher. You're targeting me. Do you:
- Use a self-signed certificate, which is going to cause my browser to pop up warnings like Satan himself is standing behind me, or
- Use plain HTTP, and include some little padlock GIFs to reassure me that things are legit?

A self-signed certificate is no more dangerous than no certificate at all. Both of them provide no assurance of legitimacy. But for some reason, browsers treat them as suspicious even though they treat unencrypted HTTP as perfectly fine.

Phishers know this. Go through your spam filter sometime. How many phishing URLs start with HTTPS? They know better than to bother with fake certificates.

Re:Only if I can use self signed certs

[spitzak]

If you are making a self-signed certificate you can also choose for it to have a very long expiration date.

Re:Only if I can use self signed certs

[Anonymous Coward]

We are also welcome to potential more distributed solutions. If you happen to have a really nice, secure protocol for a distributed namespace (although please something that works better than, say, NameCoin), please publish.

What about running your own CA. I call it eccentric-authentication.org

It builds on top of bog standard HTTPS, DNSSEC, DANE and could use a sprinkle of CT.

Guido.

Re:Only if I can use self signed certs

[hobarrera]

There's no real need for wildcard certificates; just use SNI.

Re:Only if I can use self signed certs

[hobarrera]

Or just get a free cert from startssl.com.
People using tor can use self-signed certificates, since tor user won't be strongly alarmed by unusual security warnings.

Thanks to Snowden ...

[Anonymous Coward]

Thanks to Snowden we have now an even stronger motivation to use encryption everywhere.

Re:Thanks to Snowden ...

[denis-The-menace]

What I'm worried about is that we just ASSUME it's secure because it's encrypted.

If the encryption is 128bit like the bank stuff or if the NSA/GCHQ get the CAs' Root certs.

If it is, this is nothing but "Security Theatre"

Re:Thanks to Snowden ...

[Anonymous Coward]

128 bit encryption is insecure now? As long as there are no cryptanalytic attacks I really, really don't think so. Brute-forcing 128 bits of key is a ridiculously resource-demanding operation. The only thing that could change that is a quantum computer.

Betting one beer

[fph il quozientatore]

I predict that the Unknown Powers will convince the committee to bail out and either (a) drop this idea overall (b) default to some old broken/flawed crypto protocol. Check back in 1 year.

Re:Betting one beer

[amorsen]

You can laugh at the IETF as much as you want, there are lots of things to laugh at. However, there are still a lot of very technical people involved in the IETF, and a large subset of them are finding it unpleasant that the Internet they helped create has become something very different. They are fighting the hard fight right now, and we should all support them when we can.

It is possible that the NSA or other similar dark forces may manage to subvert their intentions once more, but so far it looks like there is still hope for the good guys.

Or I may be hopelessly naive.

Re:Betting one beer

[Anonymous Coward]

Look, we're just saying that because of the crazy-theoretical BEAST attack, we're going to require you to use known-fucked algorithms like RC4 for everything if you want to be certified.

Re:Betting one beer

[Anonymous Coward]

This has happened before. Opportunistic encryption was originally a mandatory part of the IPv6 standard. Imagine that! Every connection you ever make automatically encrypted by default.

But not now. The encryption is optional and, even where IPv6 is deployed, encryption is little used. Just as the government likes it.

Re:Betting one beer

[Lennie]

Well, only slightly naive.

Because there is also a technical reason why they want to use SSL/TLS.

On the current Internet it is impossible to deploy a new HTTP-protocol like HTTP/2.0 or SPDY without TLS.

Because there are to many stupid proxy servers and ad-replacing middle boxes and other stuff that should never have been between you and the server inspecting or even manipulating the content. Trying to pass a new protocol through those boxes just doesn't work, errors is the only thing you'll get.

But you are right, they are pissed of.

I'd rather have...

[Anonymous Coward]

An encryption method that doesn't use certificate chains that can be futzed with. Perhaps a more explicit self-signed certificate methodology that could be codified in some way into http2.

Re:I'd rather have...

[gnoshi]

That's a nice idea, but the problem is that you have to trust someone to declare the certificate valid, otherwise you're just making it easier to MITM SSL connections by removing the need for intelligence agencies to lean on certificate providers to give 'fake' certificates.

https:// available soon!

[mythosaz]

...or, you know, https everything now for starters, since the processing increase is negligible.

A lot of sites are already on board.

Re:https:// available soon!

[Anonymous Coward]

Processing is negligible unless you're doing 100,000+ SSL connections per second.

Re:https:// available soon!

[mythosaz]

Will that be more or less processing than HTTP/2 with https and ssl?

Re:https:// available soon!

[Jason Levine]

Processing is negligible, but cost is not. If you are an enterprise-level organization, you should definitely go HTTPS or at least offer that as an option. If you are a hobby site running on a shared server for $10 a month, you aren't going to be able to invest in a $150 SSL certificate.

Re:https:// available soon!

[Lennie]

Actually, certificates are free. Look at StartSSL.

A VPS with it's own dedicated IP-address is 5 dollars a month, if you don't mind managing it yourself.

So where does that $150 come from ? You are using the wrong provider.

SSL only = no benefit

[girlintraining]

People think that adding encryption to something makes it more secure. No, it does not. Encryption is worthless without secure key exchange, and no matter how you dress it up, our existing SSL infrastructure doesn't cut it. It never has. It was built insecure. All you're doing is adding a middle man, the certificate authority, that somehow you're supposed to blindly trust to never, not even once, fuck it up and issue a certificate that is later used to fuck you with. www.microsoft.com can be signed by any of the over one hundred certificate authorities in your browser. The SSL protocol doesn't tell the browser to check all hundred plus for duplicates; it just goes to the one that signed it and asks: Are you valid?

The CA system is broken. It is so broken it needs to be put on a giant thousand mile wide sign and hoisted int orbit so it can be seen at night saying: "This system is fucked." Mandating a fucked system isn't improving security!

Show me where and how you plan on making key exchange secure over a badly compromised and inherently insecure medium, aka the internet, using the internet. It can't be done. No matter how you cut it, you need another medium through which to do the initial key exchange. And everything about SSL comes down to one simple question: Who do you trust? And who does the person you trusted, in turn, trust? Because that's all SSL is: It's a trust chain. And chains are only as strong as the weakest link.

Break the chain, people. Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties. That's the only way you're going to get real security... otherwise you're going to be taking a butt torpedo stamped Made At NSA Headquarters up your browser backside. And pardon me for being so blunt, but explaining the technical ins and outs is frankly beyond this crowd today. Most of you don't have the technical comprehension skills you think you do -- so I'm breaking it down for you in everyday english: Do not trust certificate authorities. Period. The end. No debate, no bullshit, no anti-government or pro-government or any politics. The system is inherently flawed, at the atomic level. It cannot be fixed with a patch. It cannot be sufficiently altered to make it safe. It is not about who we allow to be certificate authorities, or whether this organization or that organization can be trusted. We're talking hundreds of billions of dollars in revenue riding on someone's word. You would have to be weapons grade stupid to think they will never be tempted to abuse that power -- and it does not matter who you put in that position. Does. Not. Matter.

Re:SSL only = no benefit

[compro01]

What are your thoughts on RFC 6698 as a possible solution to the CA problem?

Re:SSL only = no benefit

[girlintraining]

What are your thoughts on RFC 6698 as a possible solution to the CA problem?

I think that it's already been proving that centralizing anything leads to corruption and manipulation. Whether you put it in DNS, or put it in a CA, the result is the same: Centralized control under the auspices of a third party. Any solution that doesn't allow all the power to stay in the hands of the server operator, must be rejected.

Re:SSL only = no benefit

[Anonymous Coward]

thanks mr knowitall hahaha

what a noob post...pathetic.

Re:SSL only = no benefit

[Anonymous Coward]

Is a key exchange like a key party? Cause I'm all for that! I love strange -- the stranger the better!

Re:SSL only = no benefit

[Anonymous Coward]

SSL has great key exchange mechanisms. Diffie-Hellman is the most common one, and with large enough groups and large enough keys it works very well. What works less well is the authentication bit, which is what the CAs are doing. But encryption with bad authentication, or even without authentication at all, is not worthless. It prevents passive surveillance, such as the one NSA, GHCQ and their ilk are perpetrating on hundreds of millions of internet users. Yes, you are vulnerable to man-in-the-middle attacks, but from what we have learnt from projects like the SSL Observatory, those are exceedingly rare. Always-on HTTPS would be a huge step forward and would make huge swathes of the data that semi-legal organisations like GCHQ records unusable. If you want better authentication it can be added on top of that - see e.g. Monkeysphere - but complaining when someone is trying to add a huge improvement because you don't think it's perfect is stupid.

Re:SSL only = no benefit

[Anonymous Coward]

Durrrrrrrr

Re:SSL only = no benefit

[Anonymous Coward]

thank you.

Re:SSL only = no benefit

[Anonymous Coward]

Posting anonymously for my reasons...

People think that adding encryption to something makes it more secure. Encryption is worthless without secure key exchange, and no matter how you dress it up, our existing SSL infrastructure doesn't cut it. It never has. It was built insecure.

techincally wrong. The key exchange is secure, the infrastructure managing the key trust is not trustworthy. Please do not mix the two.

Show me where and how you plan on making key exchange secure over a badly compromised and inherently insecure medium, aka the internet, using the internet. It can't be done.

Lolwut? it *CAN* be done. Personally I'm working on an alternative of TLS with federated authentication, and no X.509. The base trust will be the DNSSEC infrastructure. Sorry but you got to trust someone. I know it's not perfect, in fact as soon as I'm finished with this project (Fenrir -- will be giving a lightning talk @CCC) I think I'll start working on fixing the mess that DNSSEC is. I already have some ideas. It will take some time, but it is doable.

No matter how you cut it, you need another medium through which to do the initial key exchange.

You keep confusing the key exchange algorithm and the base of the trust for your system... are you doing this on purpose or are you just trolling?

Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties.

And give each other trust in a hippie fasion... No, you need more than that, and why does it need to be the browser? if you have a way to manage trust, why only at the browser level?

And pardon me for being so blunt, but explaining the technical ins and outs is frankly beyond this crowd today. Most of you don't have the technical comprehension skills you think you do -- so I'm breaking it down for you in everyday english: Do not trust certificate authorities. Period. The end. No debate, no bullshit, no anti-government or pro-government or any politics.

You keep talking about technical stuff and then you keep pointing at political and management problems... get your facts straight. You always make it seem as if the SSL protocol is broken per se. it is not.

The system is inherently flawed, at the atomic level. It cannot be fixed with a patch. It cannot be sufficiently altered to make it safe. It is not about who we allow to be certificate authorities, or whether this organization or that organization can be trusted.

Well, I'm working at a solution! NO X.509, trust from DNSSEC chain. That's as trustworthy as you can get. I'll work at a replacement of the DNS system after this project is finished. Keep your ears open for the "Fenrir" project, I'll be presenting it at the European CCC, although it won't be finished by then. come and discuss if you are interested. Otherwise stop spreading useless fear. -- Luca

Re:SSL only = no benefit

[girlintraining]

Why is 6698 funny? The author was serious. Now 1149? That's funny.

Re:SSL only = no benefit

[marcello_dl]

All you're doing is adding a middle man, the certificate authority, that somehow you're supposed to blindly trust to never, not even once, fuck it up and issue a certificate that is later used to fuck you with.

I would also add that, in practice, it's the third middle man. The second is the ISP.

You likely have downloaded the browser with the CA list from the net, has it been tampered with? You validate the download with checksum, gotten from the net, has it been tampered with? what about the package manager keys, are they safe?
Possibly if you have a preinstalled OS with secure credentials to communicate with a package repository you are ok, but currently that OSes come from Apple or MS, which managed to happily stay in the market when services trying to offer encrypted services have to shut down without being allowed to disclose the details. Are you going to trust them?

And the connections through ISPs likely have some proprietary OS running BGP or whatever inter-network protocols.

The first man in the middle is the hardware, keys are somewhere in ram or proc cache, hardware running malicious supervisors might just get them, while you're happy with your open source stack. (BTW I am happy with open source stacks because they tend to be written to help humans instead of articulated money traps like most commercial stuff)

Re:SSL only = no benefit

[Anonymous Coward]

No benefit, except it stops casual sniffing on hotel wifi by the guy in the next room... Where hotel wifi = any public wifi.

Keep enjoying your asthma and wood stove.

Re:SSL only = no benefit

[Luke_22]

So your solution is?
not using anything 'cause the NSA is over you?

Saying that the CA system and the DNS(SEC) infrastructure are the same is retarded.
The CA system is managed by hundred of companies, and you can not possibly know if some company as an unauthorized certificate.
Want to know if someone is giving false information on DNSSEC? "dig domainname + dnssec" should be enough....

The current (DNSSEC) system has problems, but it is not as rotten as not having anything, so it's better than nothing. Please stop denigrating it to such an extent

Re:SSL only = no benefit

[Anonymous Coward]

It is funny because everyone else, like you, recognized that 6698 is essentially the same chain of trust method as CA's,only applied to DNS.
Unlike you, everyone else also realized that compro01 is very much aware of that :-)

Re:SSL only = no benefit

[WaffleMonster]

I think that it's already been proving that centralizing anything leads to corruption and manipulation. Whether you put it in DNS, or put it in a CA, the result is the same: Centralized control under the auspices of a third party. Any solution that doesn't allow all the power to stay in the hands of the server operator, must be rejected.

Except at the end of the day you have to trust *something* and DANE is a heck of a lot better than CAs. Technical information and signing ceremony protocol intended to build trust is open and transparent.
http://www.root-dnssec.org/

As a practical matter you could use DANE simply as a more secure initial "leap of faith" and immediately work to establish a more personal trust relationship by some other means (Working zero knowledge proof for credential possession to secure your network session)

If everyone adopted this approach it would tend to limit pressure to undermine global trust anchors, limit damage due to any compromise and severely upset phishing and CA communities.

Re:SSL only = no benefit

[dgatwood]

We could start a political movement. Call it the Key Party.

Re:SSL only = no benefit

[Anonymous Coward]

I think that it's already been proving that centralizing anything leads to corruption and manipulation.

- you should attempt and remember your own statement that I quoted here the next time you talk about virtues of collectivism and socialism.

Re:SSL only = no benefit

[cloud.pt]

So true, yet so moot. Let me use numbering to address some key discrepancies on your otherwise totally intuitive, yet irrelevant arguments:

1. 1. You just discredited a system that has been successful protecting the majority of internet-bound critical use cases for years now. So I'm assuming you do absolutely no banking or social networking tasks on the WWW as you do not deem them safe enough?
2. 2. You now tell me you perform such use-cases through TOR. Too bad you just discredited TOR with that weakest link of trust argument. But you are right on that one, according to the Snowden leaks and Silk Road events, it is also unsafe. So will be Bitcoin eventually.
3. 3. A physical, "meat space" CA agreement is not going to solve all our problems, cuz' every sysop did not just gain immunity to social engineering. amiwrong? Physical CAs are definitely trustworthy because they don't abuse power either. Sure thing...

There is no such thing as perfect security, or perfect anything. There is good enough (for as long as it is deemed like that), and HTTPS enforcing is definitely BETTER than plain-text for now and forever. This is not like the Chrome "no keyring/no master password" argument: you do get bullet-proof security by mediated access, not nuke-proof, yet not everyone has nukes. That's why people bought kevlar+helmet on Counter-Strike.

So, without further metaphors: STOP CRITICIZING AN IMPROVEMENT

Re:SSL only = no benefit

[larry bagina]

Good call. If there's one thing republicans, democrats and independents; conservatives, liberals, and moderates can agree on it's that: sex with a complete stranger is the best.

What if, instead of declaring war on Iran, Barack Obama and Hassan Rouhani sat down, smoked a joint, then wife swapped? Throw in Biden and Netanyahu and you've got a gang-bang and a peace accord!

Can't you just picture them high fiving each other as they take turns busting a nut? Maybe they'd even do some double penetration. A Walk on the Wild Side wouldn't be out of the question.

Re:SSL only = no benefit

[DuckDodgers]

You're right that it only takes one compromised Certificate Authority - whether it's compromised by the NSA, hackers, or a corrupt owner - to issue what would be considered legitimate certificates for hundreds of websites like Microsoft or a bank.

But physical key exchange doesn't scale. You can't get a billion people that use desktop, laptops, tablets, or smart phones to understand how to do a physical key exchange or why it matters, let alone organize a practical way to get it done.

I don't know what the solution is, but this is a fundamental problem. A centralized authority of any kind managing key components of internet security is a very bad idea, because it's exactly where bad guys will go to poke holes in that security. But the average person isn't nearly educated enough for a distributed, user-owned alternative.

What we need is a distributed, user-owned, extraordinarily simple and easy system. I have no idea what that could be.

Re:SSL only = no benefit

[Eunuchswear]

That post should be moderated TROLL, INSIGHTFULL

Re:SSL only = no benefit

[swillden]

While you're right that there are issues with the certificate-based approach, it's not nearly as bad as you describe. There are solutions already implemented that mitigate much of the risk.

One example is certificate pinning. Google already pins all Google-owned sites in Chrome. This is actually how the DigitNotar compromise was discovered; Chrome users got an error when trying to get to a Google site.

Another example is SSH-style change monitoring, alerting users when certificates change unexpectedly. That doesn't help if the MITM attack is done from the beginning or during time periods around legitimate key changes, but it does narrow the window of opportunity significantly.

Another example is multi-perspective observation... does the same certificate get returned to multiple requesters from different places on the Internet, and is it the same one the server is actually serving (the last must be periodically verified by the the site owner).

There are other possibilities as well.

Let the browser user take control over who, how, and when, to trust. Establish places in the real world, in meat space, in bricks and mortar land, where people can go to obtain and validate keys from multiple trusted parties.

Good luck with that. You can build it, but they won't come.

Re:SSL only = no benefit

[DuckDodgers]

Oh, and as Anonymous Coward pointed out below - key exchange over the internet is secure, you can exchange keys with someone with certainty that they key has not been modified. What key exchange over the internet does not do is guarantee the identity of the other person.

You might call that a distinction without a difference, but I think it does matter.

Re:SSL only = no benefit

[dgatwood]

Wow, this thread just took a turn for the disturbing.

Re:SSL only = no benefit

[girlintraining]

So your solution is?
not using anything 'cause the NSA is over you?

My solution would firstly involve complete sentences, and secondly was already stated previously.

Please stop denigrating it to such an extent

It's shit. It's shit. It's super duper shiiiiit la de da, shit shit shit, it. is. shit. The end. I know, it doesn't exactly rhyme, but it's honest. DNSSEC is just a different color bandaid.

Re:SSL only = no benefit

[girlintraining]

Except at the end of the day you have to trust *something* and

... And nothing. If you do not exchange keys over a secure medium, then it's exploitable. You don't need fancy protocol exploits... you just need to sit between two people and pretend you're the other guy to each. You people seem to be misunderstanding what 'secure medium' means. Everything else is a bandaid. You need a secure medium or it's shit.

Re:SSL only = no benefit

[Freultwah]

OK, I'll bite. Not that I am necessarily big on collectivism and socialism, but there is nothing really inherently centralised in either. The Norwegian fishermen go fishing as a collective and it is not centralised in any shape or form, just to give an example. If you are pointing at the Soviet Union style collectivisation, then yes, that involved centralisation to an inhuman degree, but that was caused by various historic and socioeconomic factors, such as ‘that's how we've always done things in Russia’, ‘damn, the kulaks won't appreciate our kolkhozes without a central authority forcing it down their throats’, and so forth. There have been numerous examples of small scale collectivism and perhaps even socialism. You can very well have a principle of subsidiarity in place, enabling you to run a micro-scale socialist system in your parish, for example.

Re:SSL only = no benefit

[Anonymous Coward]

We could find a fix if the governments were concerned about each others' snooping. However, the governments don't mind being spied on by foreigners—their real concern is with the People, who must be kept in check and spied on. After all, modern governments are toppled by voters and not by invading armies.

Re:SSL only = no benefit

[gnoshi]

-- If this post is marked Troll, I pissed off a fanboy again.

If your post is marked troll, it is because you're being a tosser by saying:

My solution would firstly involve complete sentences, and secondly was already stated previously.

...without linking to your 'solution' (which I assume is this post).

Note: having a 'web of trust' requiring peer signing of keys for SSL is a really, really stupid idea. How big is your web of trust going to have to be to validate every possible certificate you're going to want to use? If you're trusting six degrees of separation, then how can you be even moderately confident that somewhere in your entire six degrees someone isn't a spy and thus can sign a fake key.

How much use does peer signing get even in current e-mail PGP utilisation? How useful is it when I want to validate Bob on the other side of the world and with whom I've never interacted (nor with any of Bob's friends, let alone trusting them enough to trust their signatures on a key)?

Re:SSL only = no benefit

[WaffleMonster]

... And nothing. If you do not exchange keys over a secure medium, then it's exploitable. You don't need fancy protocol exploits... you just need to sit between two people and pretend you're the other guy to each.

Your solution was for everyone to exchange keys offline which is impractical.

If you want to believe DANE is not secure channel for establishing trust that is your choice. However unless you are willing to suggest something better that can actually be deployed at scale abstract talk and wishful thinking by itself is not helpful to anyone.

My suggestion is nothing more than a hedge against future compromise of the system. With my scheme if it is known DNSSEC is compromised at some point in the future it would have no effect on those who have already established a trust relationship which at any given time would be the majority of network users. It would at least mitigate damage and buy time to get the problem fixed. Better than nothing, better than wishful thinking.

Re:SSL only = no benefit

[steffann]

I like DANE. With 'traditional' SSL certificates you are trusting some third party to certify that someone controls a certain domain name. With DANE the actual operator of the domain name can publish this. Letting the person/organisation who really controls the domain name publish the information instead of letting a third party certify something about somebody just because they pay them to do so makes so much more sense...

Re:SSL only = no benefit

[petermgreen]

You're right that it only takes one compromised Certificate Authority - whether it's compromised by the NSA, hackers, or a corrupt owner - to issue what would be considered legitimate certificates for hundreds of websites like Microsoft or a bank.

Or just by their own sloppy but widely accepted practices.

For example many SSL CAs will issue a cert to anyone who can show they can receive mail for one of a list of "likely administrative" email addresses on the domain. This creates two problems.

1: If you can insert yourself between the server and the internet then you can intercept the mail and reigster yourself a SSL cert.
2: Sometimes the site admins idea of "likely administative" addresses may not line up exactly with the CAs allowing a normal user to register themselves one of those addresses.

Re:SSL only = no benefit

[Anonymous Coward]

"Sorry but you got to trust someone."

No, you don't have to trust someone. There are distributed systems which use threshold cryptography to store and authenticate identities. See, e.g., "COCA: A Secure Distributed On-line Certication Authority (2002)" (another DARPA funded project, interestingly).

The reason systems based on DNS or IP addresses (i.e. HTTP) are hierarchical is because some central authority has to mediate namespace collisions. That's fundamentally the issue--the fact that people want short, human readable identifiers, and a provably secure way to authenticate them. Current CA systems are inextricably bound by that requirement.

If we didn't need short, human readable identifiers, we wouldn't need a hierarchical system. But we're a long way away from discarding that requirement. Although you can build some closed systems that way.

Re:SSL only = no benefit

[ultranova]

Encryption is worthless without secure key exchange

Encryption is still useful when it prevents your enemy from simply dumbing everything to be analyzed later. A MITM attack requires more resources than simply saving the packets. It's simple herd tactics: a Carnivore can still brutally tear apart any particular victim it wants, but while it does the rest get away; it can no longer make a net and catch them all to be slaughtered at its leisure.

Re:SSL only = no benefit

[Lennie]

Funny you should mention centralized, one of the reasons people dislike the current CA-system is because there are to many players.

So far, nobody has come up with a proper distributed trust model that people would trust to do their banking and similar stuff with.

Re:SSL only = no benefit

[Lennie]

The whole idea of s signing party is pretty shitty anyway. Looking at a passport from a country I've never been to to verify a person I've never met before ?

That is at least as absurd as the alternatives.

Re:SSL only = no benefit

[Lennie]

If somebody still wants the CA-system to work, we need to change the financial model. The incentive should be for them to make it as secure as possible, instead of as efficient/cheap as possible.

Re:SSL only = no benefit

[Flere Imsaho]

Do not trust certificate authorities. Period. The end. No debate, no bullshit, no anti-government or pro-government or any politics.

I keep posting this link in HTTPS discussions https://www.grc.com/fingerprints.htm

Someone's MitMing my Gmail each time I check >:-(

Re:SSL only = no benefit

[Anonymous Coward]

Here you have some decentralized solutions:
http://convergence.io/
http://perspectives-project.org/
http://web.monkeysphere.info/

There is also this project by the EFF:
https://www.eff.org/sovereign-keys

Re:SSL only = no benefit

[Srin Tuar]

>People think that adding encryption to something makes it more secure. No, it does not. Encryption is worthless without
> secure key exchange,

This is false; encrypting everything by default significantly increases the barrier to casual eavesdropping.
Letters are usually sent in sealed enveloped. Yes, someone could go to the trouble to steam them open, but
generally they dont bother. When they must bother, its expensive.

How to establish trust is a completely separate problem. Its even separable: (you could have the authentication
and tamper-resistance with no encryption at all.).

If you have been paying attention to recent events, mass-eavesdropping has been a big thing in the news lately.

Re:SSL only = no benefit

[matthewv789]

Encryption is worthless without secure key exchange.

I certainly wouldn't say that. I would say that encryption is worthless at guaranteeing protection from MITM attacks without secure key exchange. But it's far from worthless even if it doesn't do that. The vast majority of the surveillance going on is passive, not MITM, and even when you're actively targeted they're more likely to try to plant spyware on your machine than set up a MITM. Pervasive encryption protects us all from passive spying, even if the keys aren't trusted. While I don't want to imply a connection is more private or trusted than it really is, I even more don't want to discourage the use of as much opportunistic encryption as possible.

Re:SSL only = no benefit

[Anonymous Coward]

you are still trusting someone :)

It might be a group of people, but it is still trust :)

Re:SSL only = no benefit

[sverdlichenko]

It DOES make you more secure. Not every attacker is capable of planting MITM attack, and current CA infrastructure works just fine against passive eavesdropping. Some security is better then no security at all.

Re:SSL only = no benefit

[Anonymous Coward]

Personally I'm working on an alternative of TLS with federated authentication, and no X.509. The base trust will be the DNSSEC infrastructure.

Sorry but you got to trust someone. I know it's not perfect, in fact as soon as I'm finished with this project (Fenrir -- will be giving a lightning talk @CCC) I think I'll start working on fixing the mess that DNSSEC is. I already have some ideas. It will take some time, but it is doable.

IMO the simple fact that DNSsec relies on the hierarchy imposed by DNS means that it's not fixable, unless you fix the political problems first. For many techies politics is so hard that it becomes a blind spot (as Dan Kaminski perhaps unwittingly demonstrated) but that doesn't mean the problems there aren't real. They are, and worse, fixing them with technology is very hard indeed. Hence the blind spot. But we're back at the beginning: You can try and throw technology at it, but you won't get a substantially better solution, just the umpteenth reinvention and a lot of migration costs. Thus, non-starter.

No matter how you cut it, you need another medium through which to do the initial key exchange.

You keep confusing the key exchange algorithm and the base of the trust for your system... are you doing this on purpose or are you just trolling?

This is where you lose the argument in my view. You spotted what you see as confusion and you could've deigned to share your superior knowledge. Instead, you belittle. This is no basis for trust.

Re:SSL only = no benefit

[Anonymous Coward]

Posting anonymously for my reasons...

-- Luca

Really?

Re:SSL only = no benefit

[Anonymous Coward]

dude, that is one of the most common names ever, and He'll be presenting his solution anyway...

So the anonymity is in not letting people now his slashdot account -.-'

Re:SSL only = no benefit

[eibo]

Sorry but you got to trust someone.

That's a truism, as any believe in anything is based on trust in our own mind, our senses, the trustworthyness of some sources and so on. On the other hand it is definitely not necessary to trust a single entity as the DNSSEC infrastructure, giving each other trust in a hippy fashion by PGP-like infrastructures is always a possibility, even if you are clearly opposed to that.

Any system depending on the integrity of a single entitiy will be measured on the amount of power, social skills or money needed to break this integrity. Is this spreading useless fear? I don't think so.

Re:SSL only = no benefit

[DuckDodgers]

I imagine creating an effective cost structure that way would be difficult. "We demand the highest portion of the money reserved for CAs, because we have issued 0 certificates and therefore have absolute certainty that every certificate we issued is valid!"

Certificate infrastructure vulns

[Anonymous Coward]

SSL is only as good as the certificate authority regime, and the one we have in place is awful. The NSA can and does just demand the master certs and sign whatever they damn well please.

We need some sort of distributed certification authority where no one entity is in charge, probably with "bitcoin" style system to ensure cryptographic security, information distribution, etc. - Of course an anonymous system won't grant "trust" like traditional CA's supposedly (and often poorly) do. So there will still be a market for trust authorities, but they won't hold escrow over your keys with their "master" keys.

proxies

[Anonymous Coward]

Yayyy for caching proxieeess!

http 2 feature request

[advance-software]

Haven't read the spec. Please can we have a method to check whether a file exists. Apologies if it's there & I've missed it. 404 file not found isn't optimal as you get sent back a ton of unnecessary fluff. just want a bool.

Company Caching Proxies and Filtering?

[simpz]

We save about 10% of our Internet bandwidth by running all http traffic through a caching proxy. This would seem to prevent this bandwidth saving for things that just don't need encryption. This would be any public site that is largely consumable content. All in favour of it for anything more personal.

Also how are companies supposed to effectively web filter if everything is HTTPS. DNS filtering is, in general, too broad as brush. We may not like our web filtered, but companies have a legal duty that employees shouldn't be see questionable material, even if on someone else's computer. Companies have been sued for allowing this to happen.

Re:Company Caching Proxies and Filtering?

[Anonymous Coward]

All you need to do is add a CA certificate to all your browsers via group policy. Then the proxies can do man in the middle. As long as the browser trusts your certificate and the proxy signs certificates using that cert, the proxies have no problem. Bluecoat can definitely do this.

Re:Company Caching Proxies and Filtering?

[Anonymous Coward]

companies have a legal duty that employees shouldn't be see questionable material

You live in a country with fucked up laws.

Re:Company Caching Proxies and Filtering?

[Anonymous Coward]

May seem funny, but it's a real, solved issue.

You deploy your SSL Intercepting appliance's resigning key via group policy/MSI to the domain.

People without authenticated/authorized computers either bypass content inspection and filtering, or get cert warnings. Hopefully they immediately get shunted to an appropriate VLAN that... does whatever your policy is.

You'll also have to add it to the certificate store of any SSL/TLS enabled applications you run -- things like Java, curl, firefox's builtin store, .NET probably uses the windows built in... but I bet old applications might need to be relinked.

So you see, the answer to your question is... quite clearly by performing the man-in-the-middle attack on TLS infrastructure that you should already be performing on the corp network anyway. Otherwise anyone needs for a functioning drive by download/exfiltration is to use HTTPS.

By the way ... make sure your intercept appliance is not compromised.

Re:Company Caching Proxies and Filtering?

[Anonymous Coward]

You aren't up on the latest security devices companies are installing, are you? Most large companies in the US already have a built in man-in-the-middle infrastructure installed to filter https content, along with http content. Do some research. Going all https won't have one impact on a company's ability to filter content.

Now, your bandwidth reduction question is valid. Is the savings significant (in $$)?

Re:Company Caching Proxies and Filtering?

[iroll]

Also how are companies supposed to effectively web filter if everything is HTTPS.

They shouldn't. They should cut off web access for the grunts that don't need it (e.g. telecenter people who are using managed applications) and blow it wide open for those that do (engineers, creative professionals, managers). Hell, the managers are already opting out of the filtering and infecting their networks with porn viruses, so what would this change?

We may not like our web filtered, but companies have a legal duty that employees shouldn't be see questionable material, even if on someone else's computer. Companies have been sued for allowing this to happen.

Citation needed. Speaking of too broad a brush; this comment paints with a roller. I've only worked for one company that used WebSense, and that was a school. Is my anecdote more valid than yours?

Filtering is not practical for a lot of jobs, and is certainly not the gold-standard for covering-your-ass against harassment; effective management is. Let's put it this way: if a coworker creates a hostile workplace for you and the boss does everything in their power to deal with it (reprimanding and ultimately firing the offender), you can't sue the boss. If your boss doesn't do anything about it, they're gonna get sued.

Re:Company Caching Proxies and Filtering?

[Anonymous Coward]

And you make every employee's web browsing experience a nightmare (such full DPI MitM schemes tend to break anything more complicated than a static page, mostly by dropping open connections after a few minutes, which totally destroys Ajax, for example)

Re:Company Caching Proxies and Filtering?

[Teckla]

Also how are companies supposed to effectively web filter if everything is HTTPS. DNS filtering is, in general, too broad as brush. We may not like our web filtered, but companies have a legal duty that employees shouldn't be see questionable material, even if on someone else's computer. Companies have been sued for allowing this to happen.

Companies can and already do install trusted certs on the browsers of their computers, and then MITM the traffic. In other words, https would not stop them from doing any filtering they care to do.

Re:Company Caching Proxies and Filtering?

[antifoidulus]

And you make every employee's web browsing experience a nightmare (such full DPI MitM schemes tend to break anything more complicated than a static page, mostly by dropping open connections after a few minutes, which totally destroys Ajax, for example) Um, it shouldn't destroy AJAX as AJAX doesn't maintain a persistent connection. The http request that loaded the page has nothing to do with the http requests from AJAX(other than perhaps setting some cookies etc). Now what it will destroy is websockets, which do maintain an ongoing tcp connection.

Re:Company Caching Proxies and Filtering?

[Lennie]

Only for some browsers on some operating systems.

Good luck with BYOD :-)

Re:Company Caching Proxies and Filtering?

[Lennie]

I should mention that the people at the IETF working on HTTP/2.0 say how you should handle a proxy server is:

put the address of the proxy server in the browser/group policy.

Then the browser can connect to the proxy and the proxy can connect to the webserver.

You don't need to do a man-in-the-middle, that is a really stupid method.

Is there any need for HTTP 2?

[gweihir]

If there is, I do not see it. Strikes me as people that cannot stop standardizing when the problem is solved. Pretty bad. Usually ends in the "Second System Effect" (Brooks), where the second system has all the features missing in the first one and becomes unusable due to complexity.

Re:Is there any need for HTTP 2?

[TeknoHog]

Since web == http + html, I have a hard time understanding how Web 2.0 can operate with HTTP 1.x.

Re:Is there any need for HTTP 2?

[Anonymous Coward]

Is there any need for HTTP 2?

Yes. SPDY exists, and is widely used now. HTTP 2.0 brings that work into the body of W3C standards. HTTP 2.0 happens or W3C becomes irrelevant as a standards organization.

Re:Is there any need for HTTP 2?

[tepples]

HTTP 2.0 is a rebadge of Google's SPDY protocol, which uses several methods to hide Internet latency in web connections.

Re:Is there any need for HTTP 2?

[Anonymous Coward]

it already is irrelevant?

Re:Is there any need for HTTP 2?

[swillden]

Yes, there is a lot of need for HTTP 2.

HTTP was great when pages were largely just a single block of HTML, but modern pages include many separate resources which are all downloaded over separate connections, and have for a long time, actually. HTTP pipelining helps by reducing the number of TCP connections that have to be established, but they still have to be sequential per connection, and you still need a substantial number of connections to parallelize download. This all gets much worse for HTTPS connections because each connection is more expensive to establish.

HTTP 2 is actually just Google's SPDY protocol (though there may be minor tweaks in standardization, the draft was unmodified SPDY), which fixes these issues by multiplexing many requests in a single TCP connection. The result is a significant performance improvement, especially on mobile networks. HTTP 2 / SPDY adds another powerful tool as well: it allows servers to proactively deliver content that the client hasn't yet requested. It's necessary for the browser to parse the page to learn what other resources are required, and in some cases there may be multiple levels of "get A, discover B is needed, get B, discover C is needed...". With SPDY, servers that know that B, C and D are going to be needed by requesters of A can go ahead and start delivering them without waiting.

The result can be a significant increase in performance. It doesn't benefit sites that pull resources from many different domains, because each of those must be a separate connection, and it tends to provide a lot more value for sites that are already heavily optimized for performance, because those that aren't tend to have lots of non-network bottlenecks that dominate latency. Obviously it will be well-optimized sites that can make use of the server-initiated resource delivery, too.

Actually, though, Google has decided that SPDY isn't fast enough, and has built and deployed yet another protocol, called QUIC, which addresses a major remaining problem of SPDY: it's built on TCP. TCP is awesome, make no mistake, it's amazing how well it adapts to so many different network environments. But it's not perfect, and we've learned a lot about networking in the last 30 years. One specific problem that TCP has is that one lost packet will stall the whole stream until that packet loss is discovered and resent. QUIC is built on top of UDP and implements all of the TCP-analogue congestion management, flow control and reliability itself, and does it with more intelligence than can be implemented in a simple sliding window protocol.

I believe QUIC is already deployed and is available on nearly all Google sites, but I think you have to get a developer version of Chrome to see it in action. Eventually Google will (as they did with SPDY) start working with other browser makers to get QUIC implemented, and with standards bodies to get it formalized as a standard.

Relevant to the topic of the article, neither SPDY nor QUIC even have an unencrypted mode. If the committee decides that they want an unencrypted mode they'll have to modify SPDY to do it. It won't require rethinking any of how the protocol works, because SPDY security all comes from an SSL connection, so it's just a matter of removing the tunnel. QUIC is different; because SSL runs on TCP, QUIC had to do something entirely different. So QUIC has its own encryption protocol baked into it from the ground up.

Re:Is there any need for HTTP 2?

[gweihir]

Not convincing. All I see here is significantly increased complexity for a minor gain. I predict that people will curse the W3C for this in years to come.

Re:Is there any need for HTTP 2?

[swillden]

You're unlikely to see any increased complexity, unless you're actually implementing the protocol. TCP is pretty complex, but how often do you care?

As for the gain, the hundreds of milliseconds saved are really important if you are trying to create web apps with performance comparable to desktop apps.

Re:Is there any need for HTTP 2?

[Lennie]

There is no reason people can't keep using HTTP and they will, for a very long time.

Anyway it would be pretty stupid to curse the W3C for this, because W3C deals with HTML, not HTTP. The IETF are the ones that work on protocols like HTTP.

StartSSL

[tepples]

StartSSL was without charge for individuals the last time I checked. The most expensive part of SSL nowadays for a small site operated as a hobby is the dedicated IP address that you need if you want users of IE on Windows XP and Android Browser on Android 2.x to be able to access your site. These browsers don't support SNI, which allows name-based virtual hosting to work on SSL.

Re:StartSSL

[steveb3210]

IE7 on Vista or later supports SNI...

Re:StartSSL

[tepples]

Which doesn't help if you happen not to own a copy of Windows Vista or later for a particular PC, or if some of your peripherals happen to lack a working driver for Windows Vista or later. Besides, there are a lot of devices stuck on Android 2.x that will never see Ice Cream Sandwich let alone KitKat.

Re: StartSSL

[F.Ultra]

Which is why he wrote "IE on Windows XP".

Re:StartSSL

[Anonymous Coward]

Something tells me that attrition will solve the problem of Android 2.x devices and Windows XP boxes long before HTTP 2.0 is finalized. It'll be the same non-problem as the fact that I can't get a decent HTML 5 browser on my Windows 3.1 machine.

Re:StartSSL

[Eskarel]

Realistically at this point, you should either upgrade your XP install or put something other than Windows on that box. XP is a festering pile of insecure crap and needs to go. In the incredibly unlikely event that you still have a peripheral that doesn't run on anything past XP and you can't replace it with one that does you need to lock that PC down to just doing whatever the peripheral is for(I really like my printer isn't adequate at this point). Either move forward or move away, stop clinging to outdated insecure bullshit.

Re:StartSSL

[stoborrobots]

I should... certainly, and I have.

BUT... as a developer, I have clients who still use IE6 and/or IE8 on XP as their standard operating environment. So I still need my server infrastructure to cope with the wide range of client choices of software...

Re:StartSSL

[Eskarel]

It applies to them too, though I understand your dilemma. I realize Slashdot has some sort of major hard on for Windows XP, but it was full of serious design and security flaws 12 years ago and it's worse now. Even Vista for all that it was a pig at first was a better OS, 7 was pretty fantastic, 8 has some nice changes, though I'd never deploy it corporate, 8.1 plus something decent to deliver apps outside the god awful new start screen might be doable though.

Re:StartSSL

[tepples]

Realistically at this point, you should either upgrade your XP install or put something other than Windows on that box.

True, but what should I do for my Android 2.2 install on a device that doesn't have CM available?

Re:StartSSL

[Eskarel]

Well given that this standard isn't even ratified yet and we're probably talking at least two years before it's starting to roll out, throw it away and buy a new one?

Re:StartSSL

[hobarrera]

Actually, it's just IE on XP. Support for those end in april, so, it's not really an issue if IE+XP interferes with adoption to HTTP/2.0. It shouldn't be around long enough.

Re:StartSSL

[hobarrera]

There's already plenty of SNI websites out these; your clients are already having issues visiting some sites out there, and the amout of sites will only grow and grow as XP is reaching it's EOL.

Re:StartSSL

[tepples]

Actually, it's just IE on XP.

And IE on Windows Server 2003 and 2003 R2, which uses almost the same kernel as XP but is supported until July 2015. And Android Browser on Android 2.2/2.3.

Re:StartSSL

[hobarrera]

So the browser on server is keeping you from upgrading your SSL stack? Why on earth would you use a browser on a server? If you REALLY must, why not just pick another browser; if you're (for some reason) using a browser on a server, you might as well download another, it's not like you're computer-illiterate.

Re:StartSSL

[tepples]

Why on earth would you use a browser on a server?

Mostly for downloading updates to software that runs on the server. Besides, Android Browser on Android 2.2/2.3 still doesn't support SNI.

Re:StartSSL

[hobarrera]

Doesn't windows have windows update? Doesn't the server edition have remote installation mechanism analog to ssh+apt-get or something? Do you NEED a browser to maintain it?

Re:StartSSL

[tepples]

Doesn't windows have windows update?

Yes. Windows Update updates Windows. But it does not update third-party software that runs on Windows.

Re:StartSSL

[hobarrera]

I assume there's some repository-like mechanism analog to apt-get/pacman/yum for server edition, right? Or do you actually need a graphica environment to maintain a SERVER?

I agree. The idea is broken from the get go

[Marrow]

(I the user) am the one who should be purchasing trust from a vendor. A vast network of obviously compromised cert vendors should not be in my browser. They don't work for me so why are they even mentioned in my browser? There should be just one: The one I have chosen to trust. The one I pay to trust and will go out of business if they ever break the trust of their customers.
Frankly, I would prefer the trust vendor to be the same as the browser vendor. I am trusting them both, so I would rather they be the same thing.

Gee...

[Anonymous Coward]

I wish I could say something that hasn't been said already in the 10 comments posted here. This is a complete joke. Are there people who actually believe that any publicly available encryption is effective and unbroken? Please! Pull the other one.

This thread can be closed. Next story please, something about kittens, or ponies. I mean, really, get serious people... don't be such morons..

Re:Gee...

[Anonymous Coward]

Hey, you could have a look a the kitten here that I encrypted into a pony!

Usability issue, not hard technical one...

[Junta]

The problem is that all http clients see 'https' as meaning the client has a level of expectation about 'security'. Browsers have long started to do things to very obvious to denote 'good ssl' from 'bad ssl', but the expectation remains that 's' means 'meaningfully secure'.

So how best to convey 'encrypted, but don't really care about third party cert validation', which would be a must-have in a world where *every* public facing site has a TLS protected socket. Maybe a different uri scheme like 'httpe://', complete with the scare strikethroughs and such, but not with the 'are you sure, are you really really sure' that https does today...

Re:Usability issue, not hard technical one...

[xous]

This is just a matter of changing the way the URI is displayed:

NOT ENCRYPTED http:///
ENCRYPTED, NOT VERIFIED https:///
ENCRYPTED, VERIFIED https:///

With a helpful little blurb that explains (with pictures) the differences. I'm sure with some thought and a few user trails you could come up with a UI solution that most people will be able to understand well enough to know that credit card stuff should be green and that pink is better than red.

 

Re:Usability issue, not hard technical one...

[dgatwood]

I think the green versus not green covers that. IMO, anybody who doesn't have an EV certificate probably doesn't really need a TLS certificate. For everybody else, storing the public key (preferably not a fingerprint—disk space is too cheap to cut corners like that) upon the user's first visit is sufficient security.

Of course, such a scheme would bankrupt the bloated SSL cert industry and their extortion racket, but I would argue that such an outcome would be progress.

Re:Usability issue, not hard technical one...

[TheNastyInThePasty]

Normal people know that there's a difference between HTTP and HTTPS?

Re:Usability issue, not hard technical one...

[Anonymous Coward]

The problem is that verifying identity is 99% of the problem for users, encrypting is only 1%. It's far more important to be able to say "THIS IS NOT PAY PAL, DON'T GIVE THEM YOUR DETAILS" than it is to say "it's okay, your details are encrypted" (even though the latter is important).

This is why browsers warn you about visiting sites with dodgy SSL CAs, but don't warn you about submitting data in a form that's not encrypted.

Re:Usability issue, not hard technical one...

[xous]

Training users to not give out banking/payment details on anything but "green" (encrypted, verified) would not be that hard. Most already know to look for the lock icon.

Re:Usability issue, not hard technical one...

[Anonymous Coward]

The point is that what you need to do is train them to not do *anything* on a site that comes up with the "zomg, this isn't who it claims to be" dialog. Otherwise they get all kinds of exciting malware. Thus, you don't want it to become a legit thing to not be verified.

Re:Usability issue, not hard technical one...

[Anonymous Coward]

Most? what country do you live in?

Re:Usability issue, not hard technical one...

[petermgreen]

It's not that simple.

The problem is that the web uses a page by page model. Each page request is logically* a seperate "conversation" between client and server. Forms may or may not be submitted to the same hostname they are received from. Links that cross hostnames may contain sensitive information in the url.

By the time the UI elements are displayed it's TOO LATE. The request containing potentially private information has been sent. Therefore the expected security level needs to be encoded as part of the URL so that it is known to the browser when the user follows a link or clicks the submit button on a form.

* Connections may be reused to improve performance but the user has no control or expectations over that.

Re:Usability issue, not hard technical one...

[turbidostato]

"Each page request is logically* a seperate "conversation" between client and server"

Yeah, so HTTP is stateless... worthy news!

"Forms may or may not be submitted to the same hostname they are received from"

So what? Forms get defined by the one that sends them, not the one where the data finally ends up. If I'm to trust what acme.com sends, then I have to trust what acme.com sends, right?

"By the time the UI elements are displayed it's TOO LATE."

I don't think you know how HTTP works, really.

But then, you have a (minimal) point, not the one you think you have but, hey: since the conversation starts in the clear, a poisoned DNS or a MiM can send your first request to (or through) an unintended third party which, therefore, will gain knowledge about your intention to set a conversation with the intended part (hey! what happens here? why is this Oliver North talking to that Iranian guy?). Nothing unexpected but still it makes HTTPS not suitable for high confidentiality (that's what, say, tor, is meant to).

Re:Usability issue, not hard technical one...

[Lennie]

The people at the IETF basically wanted to do this:

Not encrypted: http:///
Encrypted, not verified: http:///
Encrypted, verified: https:///

The reason for this is: when a page requests has a https:/// link they actually are asking for secure.

Because encrypted, not verified is NOT secure.

It ONLY helps you against a passive attacker.

Re:Usability issue, not hard technical one...

[Lennie]

Probably not, http:/// isn't visible in the more than half of all browsers anymore.

Re:Usability issue, not hard technical one...

[matthewv789]

This behavior makes the assumption that users clearly distinguish between http and https, and significantly alter their own behavior between them. But is this true? I see no evidence that the large majority of people behave any differently over a regular http connection than over an https connection, if they even notice or are aware of the difference. I think the certificate warnings now give a disincentive to using https, for both users and for site administrators. Similarly, the silent dropping of mixed content simply breaks many https sites, again prompting people to switch back to regular http.

The warnings have become so blatant, they make a misconfigured https connection seem akin to a malware-ridden site (and mixed content may just make them unusably broken). But is this really fair? Security is about shades of risk, about probability. The VAST majority of certificate problems (self-signed, wrong hostname, expired) are not, in actuality, indicative of a MITM attack in progress. Yes, they are indicative of the risk of an undetected MITM, but 99.9+% of the time I expect you really are talking to the server you think you're talking to, etc. Very few people are ever being MITM'ed, but the NSA (and many others, I'm sure) are always listening to and recording traffic. Even if there's some risk of MITM, there's still huge value in opportunistically encrypting as much as possible against passive listening. This should be encouraged, not discouraged.

Furthermore, the green highlight and shiny lock may overstate the reliability of the CA chain of trust, considering not only all the entities that have intermediate signing certificates and of CAs potentially signing duplicate certificates on request, but the likelihood of the NSA having a sizable database of actual certificates acquired through various means, all usable in MITM attacks. And it may also overstate the ability of many forms of https to protect from decryption by various means, even during passive listening.

And why the big warnings about misconfigured https, but no warnings at all about using http? There is no conceivable circumstance in which using http is MORE secure (in any sense of the word) than even the worst possible https connection (unless users change their behavior in how they use the connection, knowing it's insecure - but I suspect few ever do). So why not constant blatant warnings about broadcasting your messages to the world, and not really knowing who you're talking to or whether the messages have been modified, when using a regular http connection?

Re:Usability issue, not hard technical one...

[matthewv789]

EXACTLY!

I also like the idea of browsers trying to opportunistically encrypt as best they can in the background. (Perhaps only in private browsing mode, or as an option selected by the user, since it would slow down page loads and might occasionally break things.) For instance, they could try every connection as https first, and if it responds on port 443, doesn't redirect back to port 80, and can do an encrypted handshake, great. No big deal if the certificate doesn't check out, or if some assets can only be loaded as http. So long as the user didn't originally request https, just do the best you can. If the certificate doesn't check out or some assets were not loaded as https, you could even report it as just http to the user (which is fine since they didn't request https and so aren't expecting it). If the user DID request https, then it could still be treated like it currently is, dropping mixed content and giving big warnings for certificate problems.

There are some add-ons that already attempt to do this, but differently. HTTPS Everywhere I think has a whitelist of sites that have been at least partially tested. KB SSL enforcer for Chrome tries https on ALL sites, but it still chokes on certificate errors and fails to load mixed content the same as normal, so the failure rate is high (often just breaking the site with no explanation, which is annoying and not usable by non-technical people).

Re:Usability issue, not hard technical one...

[Anonymous Coward]

With a sample size of 20 years of repairing computers and teaching users good practices. I can say with a good degree of certainty that most users don't know the look for the lock or https in the URL before sharing sensitive data.

It really doesn't help that browsers have been hiding the http, https, ftp, etc. I have no freaking idea why anyone would think this was a good feature aside from a lot of alcohol.

Re:Usability issue, not hard technical one...

[Anonymous Coward]

enforcing good behavior is a key ingredient. maybe the bank sites don't work on internet v2.0 and they need to step up their security to be available. that's fine and welcome and a sneaky way to enforce good (or at least) better behavior.

Re:Usability issue, not hard technical one...

[L4t3r4lu5]

In Firefox, goto about:config and flip browser.urlbar.trimURLs to false.

Re:Usability issue, not hard technical one...

[jonbryce]

They know to look for the padlock.

...DANE

[tepples]

Perhaps a more explicit self-signed certificate methodology that could be codified in some way into http2.

If your domain registrar supports DNSSEC, you could stash your certificate in a DNS record, as geekboybt mentioned.

Not to worry ...

[Anonymous Coward]

Don't worry. Microsoft has yet to competently and honestly adhere to a standard.

I'm sure IE users can look forward to non-SSL HTTP for years to come.

Re:I agree. The idea is broken from the get go

[girlintraining]

Frankly, I would prefer the trust vendor to be the same as the browser vendor. I am trusting them both, so I would rather they be the same thing.

No you don't want that. The browser developers should concern themselves with rendering the content correctly and standards-compliant, and the user-experience/interface. Separation of duties when it comes to money is paramount -- that's why you have outside accountants review your books, not internal ones. Otherwise you have the situation of creating a financial incentive to break or manipulate the system. Even one character, on one line of code, can change something from secure to exploitable. Don't tempt fate; Keep the trust chain separate from the people maintaining the protocols and infrastructure it sits on.

Still extortion...

[Junta]

You are still relying upon a third party to attest to your identity. In the DNS case, your DNS provider takes over the role of signing your stuff, and they can 'extort' you too.

Re:Still extortion...

[kthreadd]

Unless I run my own DNS, which is far easier than running a CA.

Re:Still extortion...

[Shoten]

Unless I run my own DNS, which is far easier than running a CA.

Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA. So, we're back to the "extortion" challenge again...either you run your own CA or are forced to pay someone else so that you can have a cert from theirs. I will say that at least the DNSSEC approach gets rid of the situation where any CA can give out a cert that would impersonate the valid one. In other words, the cert for www.google.com would actually be tied to www.google.com instead of having to just come from any one of the dozens of accepted CAs out in the world.

Re:Still extortion...

[syzler]

Unless I run my own DNS, which is far easier than running a CA.

Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA...

DANE (DNS-based Authentication of Named Entities) RFC6698 does NOT require the use of a recognized CA, although it does not disallow it. There are four "usage" types for certificates (excerpts from the RFC follows):

1. Certificate usage 0 is used to specify a CA certificate, or the public key of such a certificate, that MUST be found in any of the PKIX certification paths for the end entity certificate given by the server in TLS.
2. Certificate usage 1 is used to specify an end entity certificate, or the public key of such a certificate, that MUST be matched with the end entity certificate given by the server in TLS.
3. Certificate usage 2 is used to specify a certificate, or the public key of such a certificate, that MUST be used as the trust anchor when validating the end entity certificate given by the server in TLS.
4. Certificate usage 3 is used to specify a certificate, or the public key of such a certificate, that MUST match the end entity certificate given by the server in TLS.

Both Certificate usage 2 and Certificate usage 3 allow a domain's administrator to issue a certificate without requiring the involvement of a third party CA. For more information on DANE, refer to either rfc6698 or the the wikipedia article.

Re:Still extortion...

[Shoten]

Unless I run my own DNS, which is far easier than running a CA.

Not if you are using DNSSEC, it isn't. You talk about running your own DNS under those conditions as though a self-signed cert doesn't require a CA; it does. There's no such thing as certs without a CA...

DANE (DNS-based Authentication of Named Entities) RFC6698 does NOT require the use of a recognized CA, although it does not disallow it. There are four "usage" types for certificates (excerpts from the RFC follows):

1. Certificate usage 0 is used to specify a CA certificate, or
               the public key of such a certificate, that MUST be found in any of
               the PKIX certification paths for the end entity certificate given
               by the server in TLS.
2. Certificate usage 1 is used to specify an end entity
               certificate, or the public key of such a certificate, that MUST be
               matched with the end entity certificate given by the server in
               TLS.
3. Certificate usage 2 is used to specify a certificate, or the
               public key of such a certificate, that MUST be used as the trust
               anchor when validating the end entity certificate given by the
               server in TLS.
4. Certificate usage 3 is used to specify a certificate, or the
               public key of such a certificate, that MUST match the end entity
               certificate given by the server in TLS.

Both Certificate usage 2 and Certificate usage 3 allow a domain's administrator to issue a certificate without requiring the involvement of a third party CA.

For more information on DANE, refer to either rfc6698 or the the wikipedia article.

You're confusing "CA" with "third party CA." You need a CA to have a certificate. Hint: the "C" in "CA" stands for "Certificate."

I mean, I guess you could just open an editor and type something out that looks like a certificate pair, but it won't be mathematically usable, and it won't work when you try to do a Diffie-Hellman key exchange with it :)

Re:Still extortion...

[syzler]

You're confusing "CA" with "third party CA." You need a CA to have a certificate. Hint: the "C" in "CA" stands for "Certificate."

You are confusing a certificate with a certificate which most users trust (aka a Certificate Authority). A root certificate from a known Certificate Authority (i.e. an organization) is just a self signed certificate which is trusted by a large group of users. You need to have a certificate to have a CA, a CA without a certificate is well, useless.

The certificate usages 2 and 3 in the DANE specification should work with a self-signed X.509 cert and thus work without needing to involve a recognized CA, third-party CA, formal CA, or what ever you choose to call it.

I mean, I guess you could just open an editor and type something out that looks like a certificate pair, but it won't be mathematically usable, and it won't work when you try to do a Diffie-Hellman key exchange with it :)

Was this even suggested or are you trying to make yourself appear more intelligent by refuting an unmade claim which is condescendingly absurd?

Re:Still extortion...

[CBravo]

I did not dive into the subject, but how is it idifficult to run a few dns servers?

Re:Still extortion...

[GreyFish]

Quite easy, even eaiser these days - all modern dns severs do DNSSEC signing and key re generation for you. You still need to know what to put in the zone files (e.g. which records do what), the O'Reilly book is good, or you can pick it up from wikipedia / the bind admin guide / stack overflow etc..

Re:Still extortion...

[Anonymous Coward]

You're confusing "CA" with "third party CA." You need a CA to have a certificate. Hint: the "C" in "CA" stands for "Certificate."

I mean, I guess you could just open an editor and type something out that looks like a certificate pair, but it won't be mathematically usable, and it won't work when you try to do a Diffie-Hellman key exchange with it :)

openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days XXX
What CA did I use here?

Answer: None.

Re:Still extortion...

[matthewv789]

In other words, the cert for www.google.com would actually be tied to www.google.com instead of having to just come from any one of the dozens of accepted CAs out in the world.

And don't forget the intermediate signing authorities (including governments, large corporations, and even non-profits) granted that power, usually without any restrictions, by said CAs. Unlike the CAs, there is no registry of who these entities are, though a study identified quite a number of them through observing certificates from actual websites.

For instance, the US Government has dozens of certificates giving intermediate signing authority, courtesy of VeriSign.

Besides DNSSEC, there are a couple of other (very similar) initiatives currently operating that aim to better manage trust in certificates:

http://perspectives-project.org/
http://convergence.io/

Re:Still extortion...

[Khyber]

.....have you even bothered to make your own website before?

Because it seriously looks like you've not once touched a self-published cert.

Hand in your geek card.

Re:Still extortion...

[Anonymous Coward]

You are still relying upon a third party to attest to your identity.

Yes. This is a necessity.

If someone dressed in a uniform claims to be a cop you can never verify that by through him. Any kind of information he shows you can be falsified. You also can't ask his friend or ask for a number to call to verify if he is a cop because if he isn't then he will just give you the number to a friend of his who will claim that what he says is true.
Your only way of verifying his identity is through a third party that you trust. One way would be to call the police station and ask them if they have an officer at that location and if you find that insufficient ask them to contact him so that you can see that they have a connection.
If you do not trust the police station in this matter you will need another third party to verify the identity because if you trusted the one you are asking you wouldn't need to verify his identity in the first place.

It is a theoretical impossibility to be self-identifying. You always need a common trusted part to do that. If you can't find someone you trust who can attest to the identity then no identification can be done.

Re:Still extortion...

[L4t3r4lu5]

How would you protect against a MITM attack at key exchange? No third party verification of key authenticity means you need an OOB key exchange system, or the keys can be molested during negotiation.

Re:Still extortion...

[DarkOx]

It only makes it moderately harder and in practice I am not even sure its all that different in terms of posture.

In the case of a small mostly personal site that you use to communicate with yourself its win but in the more general case of you as the provider don't want someone else impersonating you to your clients not much changes going to DNS sec.

Today if someone wants to spoof my SSL site they need a server certificate from a CA the client will trust to either control the clients DNS or be able to redirect its https traffic. If you actually hijack my DNS zone, I am likely to notice, especially if I am a bank or some high value target with active monitoring and a security team.

With DNS sec you are going to still need a signing key from *any* CA the client will trust, so you can sign to fake zone that points the client where you want. Then you will need just as before to control the clients DNS in some way. I guess it closes the redirect the https traffic hole, but if you can do that you can probably just as easily fake their DNS.

Honestly while I think from an administrative perspective DNSec driven authentication of websites will work better for site operators its not much more secure against MTIM attacks than the current system. There are probably very few cases it adds anything that certificate pinning does not, which is not say your DNS resolver cannot or should not implement something similar.

Re:Still extortion...

[Anonymous Coward]

Software could cache the fingerprint of certs, so even if someone used a CA to try to MITM, the fingerprint would change, even if still signed by a trusted CA.

Re:Still extortion...

[jonbryce]

Supposing I have a public Wifi access point. I could change the DNS settings on my network to redirect traffic from your bank to my phishing site without you noticing any difference on your DNS settings. Unless I also get a security certificate for your bank's url, people trying to log on from my network will get a warning that the certificate is invalid, and probably they will decide not to proceed any further.

Re:Still extortion...

[hobarrera]

You need to use DNSSEC for this to be safe, and requires a sort-of-CA (the one that signs your domain). Otherwise, you're vulnerable to MITM.

Will users care?

[aap]

If http:// will fall back to HTTP 1.0, how does that make the Internet a more secure place? Will the users actually care that the page is being served by an older protocol, enough to type it again with https? Will they even notice?

Re:Will users care?

[gstoddart]

Well, if the browser puts up a big warning message saying "anybody can see this, are you sure?" people might understand.

In the last few months, it's been far easier to explain such things to people, because it's suddenly a real thing and is tangible.

Re:Will users care?

[Culture20]

Well, if the browser puts up a big warning message saying "anybody can see this, are you sure?"

people will look over their shoulders, see no one else in the room and that the window blinds are closed, and they'll click yes. Or they click yes out of habit.

Https with local proxy/filters?

[fahrbot-bot]

This is already a pain in the ass for me. I use a local proxy/filter (Proxomitron) to allow me to filter my HTTP streams for any application w/o having to configure them individually - or in cases where something like AdBlock would be browser specific. This doesn't work for HTTPS.

For example, Google's switch to HTTPS-only annoys me to no end as I use Proxomitron to clean up and/or disable their various shenanigans - like the damn sidebar, URL redirects, suggestions, etc... At this time using "nosslsearch.google.com" with CNAME of "www.google.com" works to get a non-encrypted page (in Proxomitron, I simply edit the "Host:" header for nosslsearch.google.com hits to be www.google.com) but who know how much longer that will last.

Thankfully, DuckDuckGo and StartPage allow me to customize their display to my liking w/o having to edit it on the fly. If only Google would get their head out of the ass and support the same, rather than only allowing their definition of "enhanced user experience".

Seriously, do we really *need* HTTPS for everything - like *most* web searches, browsing Wikipedia or News? I think not.

Re:Https with local proxy/filters?

[Chris Pimlott]

There's no reason you couldn't still use a filtering proxy. What you'll need to do is configure that filtering proxy with its own CA cert which you'll have to add to your browser's trusted CAs. The filtering proxy can terminate the outside SSL connection to the remote site (with its own list of trusted external CAs) and generate and sign its own certificates (with its configured CA cert) for the internal SSL connection to your browser. This is how BurpSuite works, for example.

Re:Https with local proxy/filters?

[Anonymous Coward]

You're the first person I've met who dislikes SSL for SSL, not the whole CA / cert thing. Your infrastructure sucks, move on.

Re:Https with local proxy/filters?

[fahrbot-bot]

What you'll need to do is configure that filtering proxy with its own CA cert which you'll have to add to your browser's trusted CAs ... This is how BurpSuite works, for example.

Proxomitron won't do that, but something else probably will - thanks (and I hadn't heard of BurpSuite).

Re:Https with local proxy/filters?

[Anonymous Coward]

Yes, since the summer-of-snowden, Wikipedia and basically everything benefits from being protected by encryption.

Re:Https with local proxy/filters?

[Lennie]

Don't do that, configure the browser to connect to the trusted proxy. That is how it is supposed to work.

Re:Https with local proxy/filters?

[Anonymous Coward]

Lets leave the whole internet vulnerable because this guy cant configure a proxy...

How would you avoid MITM?

[tepples]

So how would you recommend instead that the server operator prove his identity to members the public? Meetings in person cannot scale past a heavily local-interest web site or the web site of a business that already has thousands of brick-and-mortar locations.

Re:How would you avoid MITM?

[EvilSS]

Why not separate the "here is proof I am who I say I am" from "let's encrypt our conversation"? Web servers could easily use self-generated random certs to encrypt traffic. If you want to validate you are who you say you are, then you add a cert from a "trusted" CA to do just that. It's no different that what we have today with HTTP vs HTTPS. If I go HTTP to a site I have no assurance that they are who they say they are. At least this way the traffic is encrypted even at the lowest trust tier.

Re:How would you avoid MITM?

[girlintraining]

So how would you recommend instead that the server operator prove his identity to members the public?

I've already stated one solution; One proven to work. You just don't like it, and that's fine. But don't ask stupid questions.

Re:How would you avoid MITM?

[girlintraining]

So how would you recommend instead that the server operator prove his identity to members the public?

This problem was solved by Phillip Zimmerman, the creator of PGP... in the late 90s. Please man, just pick up a book on this before you start talking about it. You don't need to have the operator prove his identity to every single person, just a few. And people that trust that person can then have them vouch for the operator. And so on. Seven degrees of separation and social networking combine, form Captain Planet. The end.

The point is not to centralize trust chains, but to put you in control of your trust chain -- you decide who is trustworthy and who isn't. You don't have to have everyone sign everybody else's keys to accomplish this.

Re:How would you avoid MITM?

[Anonymous Coward]

> And people that trust that person can then have them vouch for the operator.

How is that not injecting MITM into the design?

Re:How would you avoid MITM?

[Shakrai]

The point is not to centralize trust chains, but to put you in control of your trust chain -- you decide who is trustworthy and who isn't. You don't have to have everyone sign everybody else's keys to accomplish this.

Perhaps the point should be to have an appropriate level of security for the task at hand. I'm not going to trust the certificate authorities with the location of the bodies I've buried, but the existing system provides sufficient security for my day to day activities. I seriously doubt anyone is going to go to the effort of compromising a CA just so they can intercept my credit card number the next time I place an Amazon order. Just what does the average person do on the internet that requires complete and unfettered trust?

Today I haven't relied upon https to secure anything more important than my /. username and password. In the last month the most important thing I've entrusted to it was my credit card number. The loss of either of these things would be a minor annoyance at best, and practically speaking neither is worth enough to justify the effort of compromising a CA and setting up a MITM attack.

The only thing I do that I want total control/trust over is remotely accessing my server. Thankfully ssh has provided for this since the very beginning. You create the private key, you control the machine it runs on, and you have the ability to easily verify the key fingerprint. If I was in a situation where I truly needed confidence in the security of my communication to another human being I would simply exchange encryption keys (better yet, one time pads) in person. I've yet to encounter such a situation in my 32 years. :)

Re:How would you avoid MITM?

[girlintraining]

'm not going to trust the certificate authorities with the location of the bodies I've buried, but the existing system provides sufficient security for my day to day activities.

Ask the people who lost tens to hundreds of millions out of their bank accounts when a CA in Africa had their root certificate's private key stolen and thousands of fake banking sites launched mere hours later, and started collecting their credentials and draining their accounts if they thought the security was "sufficient". You don't seem to understand: Your dead bodies aren't worth as much as the hundreds of millions of dollars in just consumer-based purchases that happen worldwide every day. Those rotting corpses rankling your conscience like Poe's tell tale heart may figure highly in your own thoughts... but not in the world's.

Re:How would you avoid MITM?

[WaffleMonster]

Ask the people who lost tens to hundreds of millions out of their bank accounts when a CA in Africa had their root certificate's private key stolen and thousands of fake banking sites launched mere hours later, and started collecting their credentials and draining their accounts if they thought the security was "sufficient".

If peeps had been using TLS-SRP to login to their bank accounts this would not have been possible. Fake site would be immediately detected when TLS handshake fails with a bad MAC.

Re:How would you avoid MITM?

[Shakrai]

I'm sorry, what part of my post made you think that moving tens to hundreds of millions of dollars was part of my "day to day activities"?

Compromise my online banking if you wish, it's an consumer account and you won't gain anything other than the ability to move funds between my accounts. No real way to "drain" my accounts through online banking, and even if you managed to do so my liability is limited under the law. It'd be a royal PITA to be sure, but at the end of the day I'd be made whole.

Re:How would you avoid MITM?

[Anonymous Coward]

You know, your arrogance is really getting out of hand. It is starting to make reading your posts quite difficult and I find myself skipping more and more of them.

Re:How would you avoid MITM?

[Anonymous Coward]

Please man, just pick up a book on this before you start talking about it

There you go again. I'm really sorry that your self-important majesty feels that her valuable time is being wasted having to address these stupid questions from those irritating mortals again.

HEAD request

[tepples]

What sort of "unnecessary fluff" do you get when you HEAD /thisdoesnotexist? A HEAD request is like a GET but doesn't send the response body.

Re:HEAD request

[Anonymous Coward]

thanks. will take a look tomorrow. might be sufficient

How to qualify for a visa?

[tepples]

What country is granting asylum to refugees from said "fucked up laws"?

Session cookie copying

[tepples]

This would seem to prevent this bandwidth saving for things that just don't need encryption. This would be any public site that is largely consumable content.

Please define what you mean by "consumable content". If a user is logged in, the user needs to be on HTTPS so that other users cannot copy the session cookie that identifies him. This danger of copying the session cookie is why Facebook and Twitter have switched to all HTTPS all the time. Even sites that allow viewing everything without logging in often have social recommendation buttons that connect to Facebook, Twitter, Google+, or other services that may have an ongoing session.

Re:Session cookie copying

[Anonymous Coward]

Not if you block the domain, and related domains.

Re:Session cookie copying

[tepples]

I don't see what blocking a domain has to do with sites that use a name and password. If you meant only social recommendation widgets, good luck keeping up with blocking all "related domains" that social recommendation widgets might end up using.

Re:Session cookie copying

[stewsters]

You would need a different set of cookies for http and https domains. You would always set the cookies in https, and static things like the Facebook logo could go over http with only giving away that you are loading a new page with that logo on it. This gives away information on what you are doing, but much of it can already be assumed if your computer opens a connection to Facebook's servers.

This will require a lot of micromanagement by web developers, but could be possible for large sites. Also set expires headers to not expire the logo, and you don't need to send it every time, which is far more efficient than caching it in a proxy.

Hm?

[Shoten]

One big point in favor of this plan is that if it doesn't work well (i.e., if adoption is poor), then they can add support for opportunistic encryption later. Going from opportunistic to mandatory encryption would be a much harder task.

Err...isn't going from opportunistic to mandatory encryption what they're trying to do now? Last I saw, HTTP was seeing a little bit of use already. The addition of a version number to it doesn't change the fact that they're already faced with existing behavior. It seems to me that adoption is already poor...they're just trying to force the issue now instead.

Re:Hm?

[Lennie]

HTTP/2.0 will be SSL/TLS with verified cert (CA or DNSSEC/DANE doesn't matter from IETF perspective, whatever the browser trusts).

They are debating if they want to allow HTTP/2.0 over SSL/TLS connections with unverified certs which would display as http:/// in the URL bar.

That would be a defense against passive attackers.

The reason they want to wait with allowing for unverified certs is because they expect more people to deploy TLS because of HTTP/2.0 obviously verified trumps unverifed.

The good think about unverified certs as http:/// URLs is that it can be added later.

We need MITM detection as well

[Animats]

If everything is to go SSL, we now need widespread "man-in-the-middle" intercept detection. This requires a few things:

• SSL certs need to be published publicly and widely, so tampering will be detected.
• Any CA issuing a bogus or wildcard cert needs to be downgraded immediately, even if it invalidates every cert they've issued. Browsers should be equipped to raise warning messages when this happens.
• MITM detection needs to be implemented within the protocol. This is tricky, but possible. A MITM attack results in the crypto bits changing while the plaintext doesn't. If the browser can see both, there are ways to detect attacks. Some secure phones have a numeric display where they show you two or three digits derived from the crypto stream. The two parties then verbally compare the numbers displayed. If they're different, someone is decrypting and reencrypting the bit stream.

Re:We need MITM detection as well

[stewsters]

"The two parties then verbally compare the numbers displayed"

But if there is a man in the middle, whats to stop them from changing the numbers in the voice?

It would be easy for a computer to change some checksum bits. If I have to manually talk to every customer who visits my eCommerce site to confirm their numbers each page load, I would probably walk out.

Re:We need MITM detection as well

[theripper]

Why would the crypto bits change if I intercept the packet mid-stream, copy it, send the original packet along to its destination, and decrypt the copy to peek at its juicy internals?

Re:We need MITM detection as well

[Anonymous Coward]

This is the SAS (Short Authentication String) method used in ZRTP, and it only works as long as you assume that it is unfeasible for the attacker to modify the video and audio stream in real time to make it sound like the person you are talking to are reading their faked SAS. This is not unfeasible for a text-based medium like the web.

Re:We need MITM detection as well

[Gothmolly]

You fail for using the term 'eCommerce', camel-case and all.

Re:We need MITM detection as well

[Anonymous Coward]

What I really want to see in HTTP/2 is closer integration of the website login process and the underlying TLS crypto.

Right now those are two completely orthogonal phases. What would be ideal is to use both the logon credentials and TLS session key to produce an authenticator that is known only by those who know the password.

Basically the client says, here is H(user, password, and session key) - and the servers says: yep, that matches the hash I computed, you are an authenticated user.

By linking the session key to the password the protocol creates a 2nd credential to ensure that communication is end-to-end without any intermediary. Add in diffie hellman ephemeral key negotiation and much of the problems we see today with certificate forging will be significantly weakened.

Re:We need MITM detection as well

[Animats]

Why would the crypto bits change if I intercept the packet mid-stream, copy it, send the original packet along to its destination, and decrypt the copy to peek at its juicy internals?

That requires actually breaking the cypher. That's hard, sometimes impossible with currently available compute resources. A MITM attack doesn't require breaking the cypher. The node in the middle does its own key negotiation with each end, so each end thinks it's talking to the other end. But each end is really talking to the "man in the middle" node, which has access to the plaintext and just copies it from one connection to the other.

Re:We need MITM detection as well

[Animats]

But if there is a man in the middle, whats to stop them from changing the numbers in the voice?

You can make the attacker work arbitrarily hard to fake something.

Re:We need MITM detection as well

[theripper]

Ah! Thanks for the explanation.

Re:We need MITM detection as well

[Anonymous Coward]

um, what's inherently wrong with a wildcard cert?
If I own the domain foo.com, why shouldn't I be able to leverage *.foo.com for my hosts?

Re:We need MITM detection as well

[WaffleMonster]

What I really want to see in HTTP/2 is closer integration of the website login process and the underlying TLS crypto.

Right now those are two completely orthogonal phases. What would be ideal is to use both the logon credentials and TLS session key to produce an authenticator that is known only by those who know the password.

As it stands you can use TLS-SRP to mutually authenticate passwords in a way that does not expose password to offline attack and which produces keying material to secure the session.

There have been patches sitting in chrome and firefox ticketing systems for years to enable this. On the HTTP side you set TLS identity in an environment variable.

Why it has not been pushed out seems to be lack of interest or chicken/egg problem although Apache, curl and all the major SSL toolkits support it.

Re:We need MITM detection as well

[Srin Tuar]

>MITM detection needs to be implemented within the protocol. This is tricky, but possibl

um, no, thats not true at all...

Agreed

[Marrow]

You are right. The two should remain separate, if for no other reason, then it will be easier to deprecate them individually if they screw up.

The wrong layer for (No)SSL v SSL-Only

[WaffleMonster]

I think HTTP/2 should resist the temptation to concern itself with security, concentrate on efficiently spewing hypertext and address security abstractly and cleanly at a separate layer from HTTP/2. Obviously as with HTTP/1 there are some layer dependencies but that is no excuse for even having a conversation about http vs https or opportunistic encryption. It is the wrong place.

Things change who knows some day someone may want to use something other than TLS with HTTP/2. They should be able to do so without having to suffer. Not respecting layers is how you end up with unnecessarily complex and ridged garbage.

For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?

Re:The wrong layer for (No)SSL v SSL-Only

[0123456]

For example who is to say there is no value in HTTP/2 over an IPsec protected link without TLS?

That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'

Re:The wrong layer for (No)SSL v SSL-Only

[WaffleMonster]

That is precisely the attitude that made IPSEC a bloated pig that's almost impossible for mortal man to configure: 'Who is to say there is no value in an IPSEC connection with no encryption?'

I'll see your IPSEC and raise you an H323.

Re:The wrong layer for (No)SSL v SSL-Only

[Anonymous Coward]

I respectfully disagree: it is not a layering violation, but in fact is entirely and explicitly within the scope of HTTPbis to specify that HTTP/2.0 is negotiated over TLS, just as it is entirely within the scope of the TLS WG to specify that TLS happens over TCP (and DTLS over UDP).

Going forward, after IETF 88, protocols (including HTTP/2.0) will very likely not be approved if they do not at least try to address this attack if it is possible to do so. Allowing the use of a protocol without a secure transport of some form is no longer tenable.

It is entirely reasonable to suggest that future versions of HTTP, post-2.0, may run on successors to TLS - Google themselves are experimenting with UDP transports (QUIC), although amusingly (and perhaps counterintuitively) that research is actually turning out slower than TCP at the moment, probably because the implementation's so new and experimental.

Re:The wrong layer for (No)SSL v SSL-Only

[WaffleMonster]

I respectfully disagree: it is not a layering violation, but in fact is entirely and explicitly within the scope of HTTPbis to specify that HTTP/2.0 is negotiated over TLS, just as it is entirely within the scope of the TLS WG to specify that TLS happens over TCP (and DTLS over UDP).

You are making a process argument about a standards organization. I am talking about what architecturally makes the most sense going forward. I am not concerned with process.

Going forward, after IETF 88, protocols (including HTTP/2.0) will very likely not be approved if they do not at least try to address this attack if it is possible to do so. Allowing the use of a protocol without a secure transport of some form is no longer tenable.

It is enough to say the protocol 'SHOULD' be used over a secure channel. We don't have the right to mandate what we think ought to be a minimum level of security to users. Not everyone is facing the same challenges or is operating in the same legal regime.

You and I may not like it reality is in the real world there are instances where all security is dropped at the perimeter or where end to end use of cryptography is otherwise restricted.

Re:The wrong layer for (No)SSL v SSL-Only

[Lennie]

A big reason HTTP/2.0, like SPDY, only runs over TLS on the public Internet is because of stupid proxy servers that don't understand protocol upgrades. So they encrypt it, which will make the middle box just pass it as is. Then HTTP/2.0 just works.

have been saying since https came out

[Anonymous Coward]

I've been saying we need only https everywhere since 2000.

Everything encrypted everywhere.

perpetual motion machine

[rewindustry]

IMO only - there is no such thing as automatic security.

you either have blind faith in 'organised' authorities, in whom you place your trust, or you get off your mouse and go find some other means of exchanging keys, external to the cyberverse itself.

to pretend - or wish to believe - that anything else is possible is as joe cell ignorant as it gets, and generally a waste of resources.

please prove me wrong.

Compression

[Anonymous Coward]

I hope not, I still end up on a lot of connections with ~64kbps transfer speed, which I use compression to speed up. Encrypted data, by design, doesn't compress well, so it would be a bigger pita to browse once http is phased out.

Not everyone is always on a T1 line.

Re:Compression

[raxx7]

Encrypted data does not compress well, but it's a common step to compress data before encrypting it (removing redundancy makes it harder to break encryption).
TLS (SSL) does this.
There are actually some security issue with TLS and compression (BEAST, CRIME) but they should be fixed by the time HTTP 2.0 is adopted.

This will make caching impossible

[Anonymous Coward]

I believe this will make caching impossible.

Re:This will make caching impossible

[Lennie]

No it does not, the only proxy that can cache will be a proxy you trust (or preconfigured in your browser by your employer on the computer of your employer).

Fix the Certificate Infrastructure

[PPH]

Because right now, there isn't a good way to self sign certificates without most browsers blowing chunks and scaring the crap out of uninformed users. And the CAs will get rich of the ensuing paranoia.

Not that the whole certificate infrastructure hasn't been undermined by the NSA already.

Re:I agree. The idea is broken from the get go

[Anonymous Coward]

> The one I pay to trust and will go out of business if they ever break the trust of their customers.

Has that ever actually happened? The general public doesn't even track that so the market would have a tough time responding at all to any breach(es).

Virtual hosts and extortion racketry

[J'raxis]

Are they going to redesign HTTPS to allow multiple sites on one IP (virtual hosts) and not rely on the extortion racket that is the certificate market now? Because I don't see large hosting providers buying tens of thousands of IP addresses to move all their sites to HTTPS, let alone small providers, nor do I see people wanting to add $20-100/year to their hosting bill to buy a certificate from one of the CA racketeers like Verisign.

Re:Virtual hosts and extortion racketry

[raxx7]

TLS 3.0 already allows for multiple sites on one IP.
The DANE proposal would eliminate the need to have a CA signed certificate, as long as you have DNSSEC on your domain.

Re:Virtual hosts and extortion racketry

[J'raxis]

Nice. Here's more info on that for other people who didn't know about it:

https://tools.ietf.org/html/rfc4366 (section 3.1)
http://www.internetsociety.org/articles/dane-taking-tls-authentication-next-level-using-dnssec

Currently, the payers are the websites

[Marrow]

They have an interest in -not- letting people know about security breaches. Also, there is probably momentum issues when changing a corporate website to another CA. But individual users are agile and they talk with one another. And they have no interest in being quiet. The users could abandon a security vendor quickly upon a breach. In fact, the security vendors would compete for customers on just how secure and dedicated they are to protecting their customers. The CAs are not competing for individual users at all.

Mixed content blocking

[tepples]

You would need a different set of cookies for http and https domains. You would always set the cookies in https, and static things like the Facebook logo could go over http with only giving away that you are loading a new page with that logo on it.

You can't embed images or scripts delivered through HTTP in a page or frame delivered through HTTPS without triggering browsers' mixed content blocking warnings. If a document is HTTPS, everything it refers to also has to be HTTPS.

Also set expires headers to not expire the logo, and you don't need to send it every time

Use of far-future Expires headers is a good practice, except it's not nearly as effective on mobile where caches tend to be so tiny they may as well not exist. Mobile caches are so small that Chrome for Android and Firefox for Android tend to reload documents over the Internet even if I just switched to another tab, unlike Chrome for X11/Linux and Firefox for X11/Linux that happily swap DOMs of documents in unfocused tabs out to disk.

Encrypting to the man in the middle

[tepples]

Why not separate the "here is proof I am who I say I am" from "let's encrypt our conversation"?

Because if you aren't authenticating, you're encrypting to the man in the middle.

If I go HTTP to a site I have no assurance that they are who they say they are.

When the scheme is HTTP, you have no expectation of assurance.

Re:Encrypting to the man in the middle

[EvilSS]

Yes, but at worse that puts me on par with using HTTP (again, assuming we accept that these connections are not authenticated). I'm not saying it's great, or even good security, but it would be a sight better than the plain text that we have today.

Re:Encrypting to the man in the middle

[tepples]

A user who enters HTTPS into the address bar is expecting a stronger guarantee than "on par with using HTTP".

Re:Encrypting to the man in the middle

[EvilSS]

So make HTTP encrypted, and HTTPS encrypted with authentication. How long do you want to ride this merry-go-round?

Trusting transitive trust

[tepples]

This problem was solved by Phillip Zimmerman, the creator of PGP... in the late 90s.

Yeah, I expected someone to mention the PGP web of trust. But here's something I don't understand: just because I met Aeris at a key signing party and verified her identity at a key signing party doesn't necessarily mean I feel confident in vouching for her diligence in verifying other people's identities or especially the diligence of the other people whose identity she verified.

Seven degrees of separation

It's like playing a game of telephone.

Re:Trusting transitive trust

[girlintraining]

But here's something I don't understand: just because I met Aeris at a key signing party and verified her identity at a key signing party doesn't necessarily mean I feel confident in vouching for her diligence in verifying other people's identities or especially the diligence of the other people whose identity she verified.

That's because you're looking at a network of trust as being about identity verification. That may have been what PGP key signing parties were about, but that's not the goal here. The goal in the case of websites is not to be who they say they are to a high level of reliability, it is to be enough that another website that tries to impersonate that one can be detected; In other words, to detect there's a doppleganger. So you may not trust Aeris, or her diligence.. but as long as somebody, somewhere in the chain, is checking IDs or for bullshit stories, that work is passed to everyone else. In other words, you're not building a chain... you're casting a net.

It's like playing a game of telephone.

False. The game of telephone only works when we ask humans to pass information along. We're not asking humans to pass the information on; we're asking machines to. And machines faithfully reproduce what we pass on hundreds, thousands, even billions of times, without even a single bit of error creeping in.

Re:Trusting transitive trust

[gnoshi]

The system you're proposing is interesting, but doesn't work because all you need to do to make encryption impossible is inject some dodgy keys into the system. Once you have multiple different keys for the one site which are both signed as valid, then you can't safely encrypt traffic to that site. Don't want people to be able to conduct Google searches? Generate a bunch of dodgy Google keys, get random people to sign them (because not everyone is dilligently checking IDs) and voila - no-one can trust any keys for Google any more.

Re:Trusting transitive trust

[girlintraining]

Once you have multiple different keys for the one site which are both signed as valid, then you can't safely encrypt traffic to that site.

It's the difference between tamper-resistant and tamper-evident. You get one or the other, but not both. I think tamper-evident systems are better when it comes to impersonation. I'd rather it self-destruct then let someone exploit it.

Re:Trusting transitive trust

[gnoshi]

But it is only tamper-evident if you possess more than one key for the target concurrently available. If you're only aware of one of the keys out there, then you can't detect tampering.

If the server is providing the key with attached signatures, even if you can determine a chain of trust through certificates then that doesn't help you, unless you know for sure that there are no other keys for that particular site out there which have been signed by someone else to which you can establish a chain of trust. If you have 3rd party key servers (much like currently exists for PGP encryption), then you need to check all of them, and you need to trust that they haven't all been leaned to to only keep the dodgy key, not the real key.

To try to describe more precisely:
I try to connect to 'wikipedia.org' using a secure connection. To do so, I need to get a key.
The 'wikipedia.org' server could provide me with a key, and have signatures attached to that key. I then need to be able to establish trust of one or more of those signatures to make sure I'm using a valid key.
If someone (Person A) I personally know and trust (and whose key I already) has signed the key. That's great, I can trust the key. That's about as safe as it can get.
Failing that, let's say someone (Person B) who signed the key is trusted by someone (Person A) I trust, and Person A signed the key of Person B. If I can get the key of Person B, with the signature of Person A, then I can establish a chain of trust to the 'wikipedia.org' key.
Failing that, let's say someone (Person C) who signed the key is trusted by someone (Person B) ..... etc.
So we're now out two levels, and if everyone has signed the keys of 20 other people, that means we're trusting 420 signers (excluding ourself). In practice, there will be overlap so the actual number will be less. If one of these 420 signers isn't trustworthy, they can have signed a dodgy 'wikipedia.org' key and a MITM attack can be attempted.
If the real 'wikipedia.org' key has been signed by someone I trust, and I can find that key somewhere (because presumably the server to which I am connected will feed me the dodgy certificate) then the result is that I can no longer trust either certificate. I'm stuck, and can't safely communicate with 'wikipedia.org'. I could check third-party key servers, but connections to those servers could be intercepted as well (either preventing me getting the key, or feeding me a false key). Potentially, 'trusted' key servers could have their public keys embedded in my browser, but then we just hit another problem of certification again.

Peer signing of keys, without a very sophisticated trust-weighting system, will not work simply because Dodgy Co. can manufacture a dubious certificate, get it up somewhere, and bring encryption to a particular site screaming to a halt. You wouldn't need to lean on CAs to make dodgy keys; you just make all the keys untrustworthy so no-one can use encryption.

Yes, but no

[Midnight Thunder]

My issue with https is that unless you are willing to spend the money, it is expensive to get a certificate that is suitable for a small hobby website.

Don't get me wrong, https is a good thing, but it needs to be simpler and more affordable to get a legitimate certificate.

I'll certainly be following this and see if this works out to be 'not so bad'.

So the certificate authorities paid them how much?

[Torp]

Subject says it all.

Commitees for All

[Anonymous Coward]

Luckily W3C is on the job, so we don't have to worry about it for another decade or so.

So

[damicatz]

In other words, poor people are screwed because they can't afford to fork over hundreds of dollars to Verislime for a series of prime numbers. Not to mention the fact that the average user has no idea about PKI or how to get or install a certificate (Where I work, we deal with the GSA which requires certificates for authentication and it is a never-ending headache for users).

And in the end, the people who you most want to prevent from spying on you will be able to spy on you anyways because PKI presents a centralized target for governments and they can merely bludgeon the CAs into giving them the ability to intercept stuff.

Why do people think cert warnings stop phishing?

[Anonymous Coward]

Yeah, because who cares that removing that warning allows anyone to pretend to be your bank?

If I were pretending to be your bank, I'd just use unencrypted HTTP and put up a green lock as my favicon. How many people would even notice the missing "S", or the fact that the lock is in the wrong position in the address bar?

Every time I've looked at a phishing site, it used plain HTTP.

Cert warnings don't protect against phishing, since phishing is mostly a social engineering problem. They are only useful against MITM attacks.

Mobile SSL

[maxseanmail]

Well, that goes well versed post for online users. But there's one more, mobile security system's are more complex. If you give better look, there're whom can't set it up properly and get filled with spam and hacked. Do you have anything better to solve this problem?