3 ms·

If each computer had a unique hardware private key, that could stop it. But I'm not sure that they do? (Or even if some do, can HTML5 access that somehow?)

ryansouza 12y ago
http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/ http://pilif.github.io/2008/05/why-is-nobody-using-ssl-clien...
- JetSpiegel 12y ago
  Another reason: SSL certificates cost money. StartSSL has some free option, though.
  - bri3d 12y ago
    The costs-money kind of server SSL certificates and client SSL certificates are two very different things. Client certificates are generated by the user's machine and signed using your server's private key. The user's client presents them to your server to prove that the client is who they said they were when you signed their certificate. These certificates don't cost anything, besides some CPU cycles on both sides of the process. The kind of server SSL certificates that cost money are generated by you and signed by a CA that most users' browsers will trust. Your server presents them to the client to state to the client that the server belongs to the domain it says it belongs to. Most CAs will charge you money for the service of signing those certificates, but that process has nothing to do with the lack of adoption of client SSL certificates. The parent article does a good job describing why client certificates aren't used more often: the UX doesn't make sense to users and there's not a user-friendly way to protect them with a second factor (the way you can encrypt your SSH keys using a passphrase or authentication device).
mFixman 12y ago
Couldn't the author just copy Steve's private key to his computer then?
- Xcelerate 12y ago
  Not if it's a hardware key. You give the processor something you want to encrypt, but you can't look at the actual key itself (the only way to do that would be with an electron microscope).
  - geofft 12y ago
    That said, if you could gain persistent remote access to the computer, you can just repeatedly ask the processor to encrypt things. This is incidentally part of why the Chromebook design makes it hard to persistently change the machine; a reboot starts from a clean signed image and then mounts a home directory. It's still possible to stick a persistent exploit somewhere in the home directory, but it's not as simple as just dropping a file in /etc/init.
pbhjpbhj 12y ago
Can't you just sniff for a browser fingerprint and if too many characteristics have altered end the session?
- btown 12y ago
  The problem is that the proxy that the attacker is using could ostensibly alter the outgoing messages from his phone's web browser to mimic the browser fingerprint of Steve's desktop perfectly.
bri3d 12y ago
That's the idea of a Trusted Platform Module, which many machines have had for some time. TPM provides a per-device hardware environment for signing and storing keys in a tamper-resistant manner. HTML5 can't access TPM directly, but in ChromeOS, you can create or import a client certificate as a 'hardware-backed' certificate, which is then wrapped by the device's TPM. At this point (if properly configured) an attacker can't exfiltrate client certificates from the device even with root-level access to the machine. Plus, in theory, extracting key material from the TPM should be made difficult by its manufacturer by means of various physical protections. Obviously this is a very niche edge-case, but it is possible :)

ryansouza 12y ago

http://pilif.github.io/2008/05/why-is-nobody-using-ssl-client-certificates/ http://pilif.github.io/2008/05/why-is-nobody-using-ssl-clien...

JetSpiegel 12y ago
Another reason: SSL certificates cost money. StartSSL has some free option, though.
- bri3d 12y ago
  The costs-money kind of server SSL certificates and client SSL certificates are two very different things. Client certificates are generated by the user's machine and signed using your server's private key. The user's client presents them to your server to prove that the client is who they said they were when you signed their certificate. These certificates don't cost anything, besides some CPU cycles on both sides of the process. The kind of server SSL certificates that cost money are generated by you and signed by a CA that most users' browsers will trust. Your server presents them to the client to state to the client that the server belongs to the domain it says it belongs to. Most CAs will charge you money for the service of signing those certificates, but that process has nothing to do with the lack of adoption of client SSL certificates. The parent article does a good job describing why client certificates aren't used more often: the UX doesn't make sense to users and there's not a user-friendly way to protect them with a second factor (the way you can encrypt your SSH keys using a passphrase or authentication device).

mFixman 12y ago

Couldn't the author just copy Steve's private key to his computer then?

Xcelerate 12y ago
Not if it's a hardware key. You give the processor something you want to encrypt, but you can't look at the actual key itself (the only way to do that would be with an electron microscope).
- geofft 12y ago
  That said, if you could gain persistent remote access to the computer, you can just repeatedly ask the processor to encrypt things. This is incidentally part of why the Chromebook design makes it hard to persistently change the machine; a reboot starts from a clean signed image and then mounts a home directory. It's still possible to stick a persistent exploit somewhere in the home directory, but it's not as simple as just dropping a file in /etc/init.

pbhjpbhj 12y ago

Can't you just sniff for a browser fingerprint and if too many characteristics have altered end the session?

btown 12y ago
The problem is that the proxy that the attacker is using could ostensibly alter the outgoing messages from his phone's web browser to mimic the browser fingerprint of Steve's desktop perfectly.

bri3d 12y ago

That's the idea of a Trusted Platform Module, which many machines have had for some time. TPM provides a per-device hardware environment for signing and storing keys in a tamper-resistant manner. HTML5 can't access TPM directly, but in ChromeOS, you can create or import a client certificate as a 'hardware-backed' certificate, which is then wrapped by the device's TPM. At this point (if properly configured) an attacker can't exfiltrate client certificates from the device even with root-level access to the machine. Plus, in theory, extracting key material from the TPM should be made difficult by its manufacturer by means of various physical protections. Obviously this is a very niche edge-case, but it is possible :)