51–60 of 71 posts
Earlier quoted context omitted.
I don't agree. If this happens, same rule should apply for domain name expiration.
You just made me wonder what happens if you have a cert but let the name expire. Can you MITM your old domain until the cert expires?
Earlier quoted context omitted.
Self-signed can be worse because by the same token it can be MITM'd by another self-signed cert. It would create the false illusion of security, which could lead people to provide information they otherwise would not have.
With all due respect, how is that worse than HTTP? Plain HTTP can be MITMed just as well, only that on HTTP - except that no one would do that because for HTTP, plain old packet sniffing is enough to eavesdrop on a connection. Which doesn't work for self-signed HTTPS connections. And there are in fact a lot of common scenarios where it is easy for an attacker to sniff packets but harder to establish an MITM.
Earlier quoted context omitted.
Self-signed can be worse because by the same token it can be MITM'd by another self-signed cert. It would create the false illusion of security, which could lead people to provide information they otherwise would not have.
With all due respect, how is that worse than HTTP? Plain HTTP can be MITMed just as well, only that on HTTP - except that no one would do that because for HTTP, plain old packet sniffing is enough to eavesdrop on a connection. Which doesn't work for self-signed HTTPS connections. And there are in fact a lot of common scenarios where it is easy for an attacker to sniff packets but harder to establish an MITM.
Your argument about MITM being uncommon is moot because it's not impossible and is only rare because the current system is the way that it is. Changing the system would change the attackers' methods.
Rant mode: If I understand right, getting a replacement cert doesn't result in a change of the private key anyways. It's just magically, on the expiration date, your cert is somehow insecure and we must treat it as if YOU ARE IN DANGER!! - even though it's still better than then plain HTTP that everyone uses every single goddamned day. Hell, a self signed cert is better than plain HTTP, yet for some backwards-ass rea…
Rant mode: If I understand right, getting a replacement cert doesn't result in a change of the private key anyways. It's just magically, on the expiration date, your cert is somehow insecure and we must treat it as if YOU ARE IN DANGER!! - even though it's still better than then plain HTTP that everyone uses every single goddamned day. Hell, a self signed cert is better than plain HTTP, yet for some backwards-ass rea…
A "passive eavesdropper" has all the information they need to become an active man-in-the-middle. Observe the DNS query on its way out and send your own response with your IP before the real response comes back. The client will then make its TCP connection to that injected IP.
Being able to inject traffic is not "passive".
Earlier quoted context omitted.
You just made me wonder what happens if you have a cert but let the name expire. Can you MITM your old domain until the cert expires?
Sure, if you can get the client to connect through your machine.
30 minutes, comodo reseller, seriously; You won't get SHA256, but you won't be asking your users to hurt themselves.
Earlier quoted context omitted.
With all due respect, how is that worse than HTTP? Plain HTTP can be MITMed just as well, only that on HTTP - except that no one would do that because for HTTP, plain old packet sniffing is enough to eavesdrop on a connection. Which doesn't work for self-signed HTTPS connections. And there are in fact a lot of common scenarios where it is easy for an attacker to sniff packets but harder to establish an MITM.
Worse in the sense that you expect an HTTPS connection to be secure, while you don't (or shouldn't!) expect an HTTP connection to be.
There's absolutely no reason that the most common failure modes (expiration, bare domain vs www., self signed) presents warnings that Something Fishy Is Going On®, when 9999/10000 times, there is not.
Smoke coming from my neighbor's yard in the summer might be a fire, but in all likelihood, they're running a barbecue grill. The SSL equivalent would be calling the fire department every time someone puts some steaks on.
Earlier quoted context omitted.
Worse in the sense that you expect an HTTPS connection to be secure, while you don't (or shouldn't!) expect an HTTP connection to be.
Then treat a self signed HTTPS cert as equivalent to an unsecured HTTP connection and be done with it. There's absolutely no reason that the most common failure modes (expiration, bare domain vs www., self signed) presents warnings that Something Fishy Is Going On®, when 9999/10000 times, there is not. Smoke coming from my neighbor's yard in the summer might be a fire, but in all likelihood, they're running a barbecu…
Earlier quoted context omitted.
Sure, if you can get the client to connect through your machine.
If that's the case, shouldn't all certs only be valid until the domain expires, and all domain name sales should require revocation of all certs?