Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTTP 2.0 May Be SSL-Only

Soulskill posted about a year ago | from the take-that-nsa dept.

Encryption 320

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.'"

Sorry! There are no comments related to the filter you selected.

Only if I can use self signed certs (5, Insightful)

Anonymous Coward | about a year ago | (#45415941)

otherwise this sounds like extortion from CAs

Re:Only if I can use self signed certs (5, Interesting)

geekboybt (866398) | about a year ago | (#45415965)

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.

Still extortion... (2)

Junta (36770) | about a year ago | (#45416321)

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... (2)

kthreadd (1558445) | about a year ago | (#45416407)

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

Re:Still extortion... (2)

Shoten (260439) | about a year ago | (#45416611)

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... (5, Informative)

syzler (748241) | about a year ago | (#45416953)

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 [ietf.org] or the the wikipedia article [wikipedia.org] .

Re:Only if I can use self signed certs (1)

Anonymous Coward | about a year ago | (#45416413)

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 (0)

Anonymous Coward | about a year ago | (#45416455)

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 (3, Interesting)

Anonymous Coward | about a year ago | (#45416929)

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 (5, Interesting)

Anonymous Coward | about a year ago | (#45416663)

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 (1)

denis-The-menace (471988) | about a year ago | (#45416887)

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 (3, Insightful)

Anonymous Coward | about a year ago | (#45416015)

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.

StartSSL (4, Informative)

tepples (727027) | about a year ago | (#45416251)

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 (0, Redundant)

steveb3210 (962811) | about a year ago | (#45416831)

IE7 on Vista or later supports SNI...

Re:StartSSL (1)

tepples (727027) | about a year ago | (#45416969)

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 (1)

F.Ultra (1673484) | about a year ago | (#45417005)

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

Usability issue, not hard technical one... (4, Insightful)

Junta (36770) | about a year ago | (#45416275)

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... (2)

xous (1009057) | about a year ago | (#45416459)

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

NOT ENCRYPTED http:/// [http]
ENCRYPTED, NOT VERIFIED https:/// [https]
ENCRYPTED, VERIFIED https:/// [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... (2)

dgatwood (11270) | about a year ago | (#45416633)

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... (3, Informative)

TheNastyInThePasty (2382648) | about a year ago | (#45416653)

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

Re:Only if I can use self signed certs (1)

Anonymous Coward | about a year ago | (#45416299)

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 (4, Insightful)

0123456 (636235) | about a year ago | (#45416451)

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 (0)

Anonymous Coward | about a year ago | (#45416509)

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 (2)

SteveTheNewbie (1171139) | about a year ago | (#45416957)

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 (1)

0123456 (636235) | about a year ago | (#45416963)

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 (5, Insightful)

GameboyRMH (1153867) | about a year ago | (#45416039)

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 (1)

Anonymous Coward | about a year ago | (#45416185)

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 (1)

DuckDodgers (541817) | about a year ago | (#45416859)

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 (2)

CastrTroy (595695) | about a year ago | (#45416205)

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 (1)

bunratty (545641) | about a year ago | (#45416271)

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 (1)

GameboyRMH (1153867) | about a year ago | (#45416393)

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 (3, Insightful)

girlintraining (1395911) | about a year ago | (#45416195)

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 (3, Interesting)

i kan reed (749298) | about a year ago | (#45416257)

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 (2)

girlintraining (1395911) | about a year ago | (#45416381)

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 (4, Insightful)

i kan reed (749298) | about a year ago | (#45416415)

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 (1)

Jason Levine (196982) | about a year ago | (#45417011)

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 (1)

Alain Williams (2972) | about a year ago | (#45416301)

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 [wikipedia.org] 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 [wikipedia.org] 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 (0)

Anonymous Coward | about a year ago | (#45416503)

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

Re:Only if I can use self signed certs (1)

bsdasym (829112) | about a year ago | (#45416627)

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.

Thanks to Snowden ... (0)

Anonymous Coward | about a year ago | (#45415981)

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

Betting one beer (2)

fph il quozientatore (971015) | about a year ago | (#45415987)

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 (4, Insightful)

amorsen (7485) | about a year ago | (#45416189)

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 (0)

Anonymous Coward | about a year ago | (#45416357)

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.

I'd rather have... (1)

Anonymous Coward | about a year ago | (#45415991)

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.

...DANE (1)

tepples (727027) | about a year ago | (#45416283)

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 [slashdot.org] .

https:// available soon! (1)

mythosaz (572040) | about a year ago | (#45416001)

...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! (0)

Anonymous Coward | about a year ago | (#45416197)

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

Re:https:// available soon! (1)

mythosaz (572040) | about a year ago | (#45416231)

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

SSL only = no benefit (5, Insightful)

girlintraining (1395911) | about a year ago | (#45416027)

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 (5, Insightful)

compro01 (777531) | about a year ago | (#45416081)

What are your thoughts on RFC 6698 [ietf.org] as a possible solution to the CA problem?

Re:SSL only = no benefit (3, Interesting)

girlintraining (1395911) | about a year ago | (#45416213)

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.

How would you avoid MITM? (1)

tepples (727027) | about a year ago | (#45416411)

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:SSL only = no benefit (1)

Luke_22 (1296823) | about a year ago | (#45416639)

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 (0)

WaffleMonster (969671) | about a year ago | (#45416679)

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/ [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 (0)

Anonymous Coward | about a year ago | (#45416753)

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 (1)

girlintraining (1395911) | about a year ago | (#45416419)

Why is 6698 funny? The author was serious. Now 1149 [ietf.org] ? That's funny.

Re:SSL only = no benefit (0)

Anonymous Coward | about a year ago | (#45416677)

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 (0)

Anonymous Coward | about a year ago | (#45416223)

thanks mr knowitall hahaha

what a noob post...pathetic.

Re:SSL only = no benefit (0)

Anonymous Coward | about a year ago | (#45416229)

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 (1)

dgatwood (11270) | about a year ago | (#45416703)

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

Re:SSL only = no benefit (2)

larry bagina (561269) | about a year ago | (#45416949)

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 (3, Insightful)

Anonymous Coward | about a year ago | (#45416247)

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 (0)

Anonymous Coward | about a year ago | (#45416255)

Durrrrrrrr

I agree. The idea is broken from the get go (2)

Marrow (195242) | about a year ago | (#45416259)

(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.

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

girlintraining (1395911) | about a year ago | (#45416313)

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.

Agreed (1)

Marrow (195242) | about a year ago | (#45416733)

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.

Re:SSL only = no benefit (0)

Anonymous Coward | about a year ago | (#45416325)

thank you.

Re:SSL only = no benefit (5, Interesting)

Anonymous Coward | about a year ago | (#45416375)

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 (1)

marcello_dl (667940) | about a year ago | (#45416587)

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 (0)

Anonymous Coward | about a year ago | (#45416597)

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 (2)

cloud.pt (3412475) | about a year ago | (#45416813)

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 (1)

DuckDodgers (541817) | about a year ago | (#45416971)

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.

Certificate infrastructure vulns (0)

Anonymous Coward | about a year ago | (#45416067)

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 (0)

Anonymous Coward | about a year ago | (#45416091)

Yayyy for caching proxieeess!

http 2 feature request (1)

advance-software (1770510) | about a year ago | (#45416131)

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.

HEAD request (1)

tepples (727027) | about a year ago | (#45416461)

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.

Company Caching Proxies and Filtering? (4, Insightful)

simpz (978228) | about a year ago | (#45416167)

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? (1)

Anonymous Coward | about a year ago | (#45416319)

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? (-1)

Anonymous Coward | about a year ago | (#45416623)

That doesn't seem to be a valid solution for externally facing websites...

Re:Company Caching Proxies and Filtering? (1)

Anonymous Coward | about a year ago | (#45416433)

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

You live in a country with fucked up laws.

How to qualify for a visa? (1)

tepples (727027) | about a year ago | (#45416473)

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

Session cookie copying (1)

tepples (727027) | about a year ago | (#45416545)

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" [gnu.org] . 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 (0)

Anonymous Coward | about a year ago | (#45416865)

Not if you block the domain, and related domains.

Re:Session cookie copying (1)

tepples (727027) | about a year ago | (#45416995)

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:Company Caching Proxies and Filtering? (1)

Anonymous Coward | about a year ago | (#45416671)

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? (0)

Anonymous Coward | about a year ago | (#45416989)

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 $$)?

Is there any need for HTTP 2? (2, Interesting)

gweihir (88907) | about a year ago | (#45416173)

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? (1)

TeknoHog (164938) | about a year ago | (#45416615)

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? (0)

Anonymous Coward | about a year ago | (#45416689)

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? (1)

tepples (727027) | about a year ago | (#45416725)

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

Gee... (0)

Anonymous Coward | about a year ago | (#45416269)

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..

Not to worry ... (0)

Anonymous Coward | about a year ago | (#45416307)

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.

Will users care? (2)

aap (108982) | about a year ago | (#45416333)

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? (1)

gstoddart (321705) | about a year ago | (#45416513)

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.

Https with local proxy/filters? (3, Interesting)

fahrbot-bot (874524) | about a year ago | (#45416395)

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? (1)

Chris Pimlott (16212) | about a year ago | (#45416567)

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.

Hm? (1)

Shoten (260439) | about a year ago | (#45416643)

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.

We need MITM detection as well (3, Insightful)

Animats (122034) | about a year ago | (#45416729)

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.

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

WaffleMonster (969671) | about a year ago | (#45416893)

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?

have been saying since https came out (0)

Anonymous Coward | about a year ago | (#45416939)

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

Everything encrypted everywhere.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?