4 ms·

I trust more my first time connection to a website than so random authority a random country signing it, it’s that simple. But the money grab is so big that the

by Buetol 8y ago

I trust more my first time connection to a website than so random authority a random country signing it, it’s that simple. But the money grab is so big that they keep existing ! EDIT: And you’re saying the SSH model is broken then. Also you can verify the certificate signature via another channel, like a git repo of all the signatures of most important websites (I know, it look like a CA)

rileymat2 8y ago
Maybe it my problem, because I don't understand all my options. But when I spin up a new cloud server built on some image from a cloud provider, I am not sure how I can verify this certificate. How can I verify I am not being Mitm'ed on this new server? Or maybe the cloud provider is dropping the ball in not giving me the fingerprint when I request its creation? But yes, it does seem broken to me.
- Buetol 8y ago
  I don’t quite grasp your question but when you setup an instance, the hosting provider can provide you the SSH fingerprint of the server for you to check the first connection
Karunamon 8y ago
A few problems: 1. SSH's whining about first connection fingerprint trusting is needlessly petty and nobody actually checks the fingerprints, and in many cases they have no need to do so anyways. 2. Almost all cert errors a user will encounter in the real world are the fault of misconfiguration (wrong domain) or pathological/greed-driven behavior (expiration) rather than something that actually impacts the confidentiality of the connection (which is what we care about). 3. The fact that all cert errors are treated as the same severity (red screen! exclamation points!!1 YOU ARE IN DANGER!!!1one) conditions people to click by them without thought.
- charleslmunger 8y ago
  > A few problems: > 1. SSH's whining about first connection fingerprint trusting is needlessly petty and nobody actually checks the fingerprints, and in many cases they have no need to do so anyways. I disagree, but this is really a question of configured defaults and security UX. The first connection you make to a server is not secure, and impacts the security of all subsequent requests to that server. > 2. Almost all cert errors a user will encounter in the real world are the fault of misconfiguration (wrong domain) or pathological/greed-driven behavior (expiration) rather than something that actually impacts the confidentiality of the connection (which is what we care about). This is the great success of TLS - attacks are so rare that most users won't encounter them. Misconfiguration is indistinguishable from an attack, so the only reasonable thing to do is to warn the user as if it is an attack. Expiration is not a money grab, especially since the CA with the shortest expiration is also completely free. Expiration is a great thing. It limits the window of vulnerability for compromised certificates, and means that revocation lists like those shipped by chrome do not have to grow endlessly large, since expired certificates can be pruned. > 3. The fact that all cert errors are treated as the same severity (red screen! exclamation points!!1 YOU ARE IN DANGER!!!1one) conditions people to click by them without thought. With HSTS, that's not an option - and chrome can be configured by sites and enterprises to disallow bypassing certificate warnings. For example, try bypassing this one: https://pinning-test.badssl.com/ https://pinning-test.badssl.com/
  - Operyl 8y ago
    Interesting. I thought Safari in iOS would block it, but I guess that is just chrome still.
deleted 8y ago
[deleted]
Spivak 8y ago
Re: Your edit. SSH actually follows the same model as SSL in this respect. It's just that basically everyone goes self-signed and there isn't a big institutional system to distribute SSH CA's. It's more common in enterprisey environments where you have config management to distribute the CA but you can do it right now https://www.lorier.net/docs/ssh-ca.html https://www.lorier.net/docs/ssh-ca.html

by Buetol 8y ago

rileymat2 8y ago

Maybe it my problem, because I don't understand all my options. But when I spin up a new cloud server built on some image from a cloud provider, I am not sure how I can verify this certificate. How can I verify I am not being Mitm'ed on this new server? Or maybe the cloud provider is dropping the ball in not giving me the fingerprint when I request its creation? But yes, it does seem broken to me.

Buetol 8y ago
I don’t quite grasp your question but when you setup an instance, the hosting provider can provide you the SSH fingerprint of the server for you to check the first connection

Karunamon 8y ago

A few problems: 1. SSH's whining about first connection fingerprint trusting is needlessly petty and nobody actually checks the fingerprints, and in many cases they have no need to do so anyways. 2. Almost all cert errors a user will encounter in the real world are the fault of misconfiguration (wrong domain) or pathological/greed-driven behavior (expiration) rather than something that actually impacts the confidentiality of the connection (which is what we care about). 3. The fact that all cert errors are treated as the same severity (red screen! exclamation points!!1 YOU ARE IN DANGER!!!1one) conditions people to click by them without thought.

charleslmunger 8y ago
> A few problems: > 1. SSH's whining about first connection fingerprint trusting is needlessly petty and nobody actually checks the fingerprints, and in many cases they have no need to do so anyways. I disagree, but this is really a question of configured defaults and security UX. The first connection you make to a server is not secure, and impacts the security of all subsequent requests to that server. > 2. Almost all cert errors a user will encounter in the real world are the fault of misconfiguration (wrong domain) or pathological/greed-driven behavior (expiration) rather than something that actually impacts the confidentiality of the connection (which is what we care about). This is the great success of TLS - attacks are so rare that most users won't encounter them. Misconfiguration is indistinguishable from an attack, so the only reasonable thing to do is to warn the user as if it is an attack. Expiration is not a money grab, especially since the CA with the shortest expiration is also completely free. Expiration is a great thing. It limits the window of vulnerability for compromised certificates, and means that revocation lists like those shipped by chrome do not have to grow endlessly large, since expired certificates can be pruned. > 3. The fact that all cert errors are treated as the same severity (red screen! exclamation points!!1 YOU ARE IN DANGER!!!1one) conditions people to click by them without thought. With HSTS, that's not an option - and chrome can be configured by sites and enterprises to disallow bypassing certificate warnings. For example, try bypassing this one: https://pinning-test.badssl.com/ https://pinning-test.badssl.com/
- Operyl 8y ago
  Interesting. I thought Safari in iOS would block it, but I guess that is just chrome still.

deleted 8y ago

[deleted]

Spivak 8y ago

Re: Your edit. SSH actually follows the same model as SSL in this respect. It's just that basically everyone goes self-signed and there isn't a big institutional system to distribute SSH CA's. It's more common in enterprisey environments where you have config management to distribute the CA but you can do it right now https://www.lorier.net/docs/ssh-ca.html https://www.lorier.net/docs/ssh-ca.html