4 ms·

An untrusted cert is strictly no different than plaintext. Replacing "a plaintext exchange with your attacker" with "an encrypted but unauthenticated exchange w

An untrusted cert is strictly no different than plaintext. Replacing "a plaintext exchange with your attacker" with "an encrypted but unauthenticated exchange with your attacker" is rearranging deckchairs on the Titanic after it's hit the ocean floor

bandrami 10y ago
Wrong. You know that no party other than the sender has read or altered the resource in transit. Do you really not see the difference there? I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides. Why people ignore such an obvious point is beyond me.
- blueplanet200 10y ago
  I think the point is if a cert is suddenly from an untrusted source it's a sign of malicious activity, hence the increased negative feedback to the user relative to an insecure connection. Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
- mikeash 10y ago
  It can be eavesdropped or altered by MITMing the connection and substituting a different untreated certificate. With trusted certs, you have a reasonably strong assurance that you're talking to the domain owner, even though you may not know who that is.
  - bandrami 10y ago
    Sigh. No. Again: I link to my blog, with HTTPS You have no idea who I am. "Bandrami" is not a meaningful string to you. What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.
    - Flimm 10y ago
      When I click on a link someone has sent me, I want to see what the server at that link is sending me. I don't want to see what a MITM is sending me. Maybe I shouldn't trust the person who sent me the link and/or the method it was sent. But maybe I have good reason to. Why should you assume weaknesses in a previous link on the chain in order to justify a weakness in the link of the chain that is being discussed?
    - jedberg 10y ago
      It means that if I'm at Starbucks and I want to read "bandrami's" blog, I know that the guy in the corner with the Pineapple hasn't changed the content, because Thawte has at least verified that bandrami.com is the one who actually requested the cert.
      - ubernostrum 10y ago
        What I care about is the admin interface of my blog. I want that, and only that, to live on a secure connection, for me and only me. I literally just want to be able to type in the password to my blog so I can post stuff to it. Why does this have to be forced to be such a jump-through-hoops-and-pay-strangers-money thing? Why shouldn't I just make my own cert, note its fingerprint, and call it a day? Why does my browser have to repeatedly go absolutely apeshit over that? And more importantly, if this is really such a massive unbelievable vector that literally every web-connected computer on earth must behave this way, why does SSH still just say "want to trust this key? OK, I'll get out of your way now"?
        pfg 10y ago
        To put it bluntly: The inconvenience caused to you (and other users who might be able to make an informed decision when facing a certificate warning) is less important than the risk that a non-technical user accepts a certificate mistakenly and falls victim to a MitM attack. Oh, and every browser I'm aware of allows you to import CA certificates, so why not just do that once and get a nice, green lock? I don't know many non-technical users who use SSH regularly, but even for technical users, I doubt too many check the fingerprint, so the TOFU property of SSH is still a problem. That being said, SSH's TOFU is not all that different from the process of installing a CA certificate in your browser so ... just do that.
  - angry-hacker 10y ago
    Cloudflare free flexible ssl plan, powers a lot of internet - - do you know you talk to server of the owner? No. You even don't know if cloudflare is transmitting everything in plain text after reaching them. Probably most of the time it does. Https is current form is snake oil.
    - Flimm 10y ago
      HTTPS in any form would not stop Cloudflare from doing what you describe. Think about it, an encryption system that stops an end-point server from passing decrypted data to somewhere else is basically impossible. It would mean finding a DRM scheme that actually worked, and we know that's impossible because of the analog hole. The only way to stop this would be for the end-point server to be unable to decrypt the data ever, but still manipulate it. That's called homonorphic encryption and it's still only theoretical.
    - deleted 10y ago
      [deleted]
- zigzigzag 10y ago
  I think the point of dispute is something like this: 1) Yes, browsers could accept SSL with a bad cert chain and just show the UI as if it was plain text. However, then they'd need to have multiple codepaths to support what should be a very rare occurrence, in a very security sensitive part of the code: you have to teach the address bar to display http:// http:// when it's really https etc, because otherwise you're diluting the meaning of https, but URLs themselves still say https, etc. It's just complicated. 2) Your justification for why it's meaningful doesn't really work: if browsers used very long lived connections then it might be helpful but they don't, they re-negotiate and re-establish connections constantly. If an eavesdropper wants to MITM you and you aren't doing cert checking then they just need to wait a minute or two until you click another link on the page. It's not an especially interesting security upgrade. In your blog example you don't know the blog wasn't altered in transmission.
marcosdumay 10y ago
Exactly. And it should receive the exact same treatment. (And, yes, browsers are finally fixing this by warning on plaintext pages. About time.)

bandrami 10y ago

Wrong. You know that no party other than the sender has read or altered the resource in transit. Do you really not see the difference there? I have a blog. If I link to it here with HTTPS, you still have no idea who I am. A third party's assurance that I am who I say I am doesn't help you, because you still don't know who I am. What you care to know is that nobody has read or altered the contents of the transmission (yes: it's possible you're being phished, but that was true before -- now you know this phishing attempt is not also being eavesdropped or itself altered). Which untrusted SSL provides. Why people ignore such an obvious point is beyond me.

blueplanet200 10y ago
I think the point is if a cert is suddenly from an untrusted source it's a sign of malicious activity, hence the increased negative feedback to the user relative to an insecure connection. Granted this opens up attacks like ssl stripping, https://github.com/moxie0/sslstrip https://github.com/moxie0/sslstrip, but certificate pinning is making that more difficult.
mikeash 10y ago
It can be eavesdropped or altered by MITMing the connection and substituting a different untreated certificate. With trusted certs, you have a reasonably strong assurance that you're talking to the domain owner, even though you may not know who that is.
- bandrami 10y ago
  Sigh. No. Again: I link to my blog, with HTTPS You have no idea who I am. "Bandrami" is not a meaningful string to you. What does Thawte's assurance that I am who I claim to be add to this situation? You shouldn't trust your MITM'er any more than you should trust a verified me.
  - Flimm 10y ago
    When I click on a link someone has sent me, I want to see what the server at that link is sending me. I don't want to see what a MITM is sending me. Maybe I shouldn't trust the person who sent me the link and/or the method it was sent. But maybe I have good reason to. Why should you assume weaknesses in a previous link on the chain in order to justify a weakness in the link of the chain that is being discussed?
  - jedberg 10y ago
    It means that if I'm at Starbucks and I want to read "bandrami's" blog, I know that the guy in the corner with the Pineapple hasn't changed the content, because Thawte has at least verified that bandrami.com is the one who actually requested the cert.
    - ubernostrum 10y ago
      What I care about is the admin interface of my blog. I want that, and only that, to live on a secure connection, for me and only me. I literally just want to be able to type in the password to my blog so I can post stuff to it. Why does this have to be forced to be such a jump-through-hoops-and-pay-strangers-money thing? Why shouldn't I just make my own cert, note its fingerprint, and call it a day? Why does my browser have to repeatedly go absolutely apeshit over that? And more importantly, if this is really such a massive unbelievable vector that literally every web-connected computer on earth must behave this way, why does SSH still just say "want to trust this key? OK, I'll get out of your way now"?
      - pfg 10y ago
        To put it bluntly: The inconvenience caused to you (and other users who might be able to make an informed decision when facing a certificate warning) is less important than the risk that a non-technical user accepts a certificate mistakenly and falls victim to a MitM attack. Oh, and every browser I'm aware of allows you to import CA certificates, so why not just do that once and get a nice, green lock? I don't know many non-technical users who use SSH regularly, but even for technical users, I doubt too many check the fingerprint, so the TOFU property of SSH is still a problem. That being said, SSH's TOFU is not all that different from the process of installing a CA certificate in your browser so ... just do that.
- angry-hacker 10y ago
  Cloudflare free flexible ssl plan, powers a lot of internet - - do you know you talk to server of the owner? No. You even don't know if cloudflare is transmitting everything in plain text after reaching them. Probably most of the time it does. Https is current form is snake oil.
  - Flimm 10y ago
    HTTPS in any form would not stop Cloudflare from doing what you describe. Think about it, an encryption system that stops an end-point server from passing decrypted data to somewhere else is basically impossible. It would mean finding a DRM scheme that actually worked, and we know that's impossible because of the analog hole. The only way to stop this would be for the end-point server to be unable to decrypt the data ever, but still manipulate it. That's called homonorphic encryption and it's still only theoretical.
  - deleted 10y ago
    [deleted]
zigzigzag 10y ago
I think the point of dispute is something like this: 1) Yes, browsers could accept SSL with a bad cert chain and just show the UI as if it was plain text. However, then they'd need to have multiple codepaths to support what should be a very rare occurrence, in a very security sensitive part of the code: you have to teach the address bar to display http:// http:// when it's really https etc, because otherwise you're diluting the meaning of https, but URLs themselves still say https, etc. It's just complicated. 2) Your justification for why it's meaningful doesn't really work: if browsers used very long lived connections then it might be helpful but they don't, they re-negotiate and re-establish connections constantly. If an eavesdropper wants to MITM you and you aren't doing cert checking then they just need to wait a minute or two until you click another link on the page. It's not an especially interesting security upgrade. In your blog example you don't know the blog wasn't altered in transmission.

marcosdumay 10y ago

Exactly. And it should receive the exact same treatment. (And, yes, browsers are finally fixing this by warning on plaintext pages. About time.)