4 ms·

I'm no cryptographer, but doesn't ChannelID (and, to a lesser extent, certificate pinning) mitigate a lot of these concerns? certificate pinning is already in

by codeka 13y ago

I'm no cryptographer, but doesn't ChannelID (and, to a lesser extent, certificate pinning) mitigate a lot of these concerns? certificate pinning is already in Chrome, and I think ChannelID is coming soon (if not already). ChannelID: http://tools.ietf.org/html/draft-balfanz-tls-channelid-00 http://tools.ietf.org/html/draft-balfanz-tls-channelid-00

cbhl 13y ago
Perhaps, but I imagine it will easily be a decade before >90% of deployments are on browser versions that support Cert Pinning and ChannelID... think of all those enterprise deployments, universities and banks.
kniht 13y ago
It looks like ChannelID has been enabled since Chrome 24[1]. [1] https://code.google.com/p/chromium/issues/detail?id=136462#c6 https://code.google.com/p/chromium/issues/detail?id=136462#c...
graue 13y ago
I hadn't heard of ChannelID before now, but that draft is clearly talking about client, not server authentication; it's a way for you to prove to HN that you're really 'codeka', not a way for HN to prove to you that it's really Hacker News (which is what SSL certs do).
- codeka 13y ago
  It protects against more than that, from the RFC: > There are four classes of attackers against which we consider our security guarantees: passive network attackers, active network attackers, active network attackers with misissued certificates and attackers in possession of the legitimate server's private key. Basically (and this is just my understanding), it should mean a MITM cannot decode the encrypted stream even if he has the legitimate server's private key.
  - agl 13y ago
    That section is dealing purely with an attacker who wants to impersonate a ChannelID. It's correct that an attacker cannot fool the real server into believing that it is in possession of a ChannelID, even if the attacker has the server's private key (so long as the server is forward secure). However, that doesn't mean that the client isn't fooled. (Disclosure: I wrote that section of the draft.)
belorn 13y ago
The certificate pinning in chrome is not an universal solution to the problem. It just a built-in list from google that hardcode what certificates are "correct" for a short list of domains. The RFC for expanding the concept to a more universal approach is to do as ssh, by remembering certain attributes from the first time a client connect to a server. ChannelID seems to operate in the same fashion. The first connection from Client->Server is completely without any security, but further connections can be verified.

by codeka 13y ago

cbhl 13y ago

Perhaps, but I imagine it will easily be a decade before >90% of deployments are on browser versions that support Cert Pinning and ChannelID... think of all those enterprise deployments, universities and banks.

kniht 13y ago

It looks like ChannelID has been enabled since Chrome 24[1]. [1] https://code.google.com/p/chromium/issues/detail?id=136462#c6 https://code.google.com/p/chromium/issues/detail?id=136462#c...

graue 13y ago

I hadn't heard of ChannelID before now, but that draft is clearly talking about client, not server authentication; it's a way for you to prove to HN that you're really 'codeka', not a way for HN to prove to you that it's really Hacker News (which is what SSL certs do).

codeka 13y ago
It protects against more than that, from the RFC: > There are four classes of attackers against which we consider our security guarantees: passive network attackers, active network attackers, active network attackers with misissued certificates and attackers in possession of the legitimate server's private key. Basically (and this is just my understanding), it should mean a MITM cannot decode the encrypted stream even if he has the legitimate server's private key.
- agl 13y ago
  That section is dealing purely with an attacker who wants to impersonate a ChannelID. It's correct that an attacker cannot fool the real server into believing that it is in possession of a ChannelID, even if the attacker has the server's private key (so long as the server is forward secure). However, that doesn't mean that the client isn't fooled. (Disclosure: I wrote that section of the draft.)

belorn 13y ago

The certificate pinning in chrome is not an universal solution to the problem. It just a built-in list from google that hardcode what certificates are "correct" for a short list of domains. The RFC for expanding the concept to a more universal approach is to do as ssh, by remembering certain attributes from the first time a client connect to a server. ChannelID seems to operate in the same fashion. The first connection from Client->Server is completely without any security, but further connections can be verified.