5 ms·

Yeah, I'd be interested to understand the circumstances that lead to them opening and clicking a link in an email this old.

londons_explore 6y ago
During a migration from one email system to another, it wouldn't be unusual for some virus scanner product to click every link in every email... Or alternatively, when searching their inbox for "SSL certificate" they found the verification email and clicked the link as a quick way to get to the homepage of whichever company they used last time for their certificate.
- comex 6y ago
  Or they searched for SSL certificate, found the email, and didn’t notice the date. Perhaps it was marked unread, given that the email verification was never completed in 2010. They thought it was something they needed to do, and did it.
- tialaramex 6y ago
  It's definitely plausible that the historic URLs which caused this are vulnerable to just being opened automatically by a machine (such as a "virus scanner"). The right fix here is that the URL leads to a simple POST form where you confirm you want the certificate issued. Tools like virus scanners don't fill out forms. We know that by the time the Ten Blessed Methods were coming into existence CAs were discovering that they had numerous cases where an order would be successfully "validated" by contact with a human, but without any human actually doing anything. Email links "clicked" by automated systems, a system that checks you've uploaded a file to your web server treats the 404 error it gets as an acceptable response showing the file was uploaded, several hilarious goofs. [ The irony, for those playing along at home, is that we don't know of any incidents where this was used for an attack. It's like coming home to discover the reason you didn't have your front door key is because you left it on the kitchen counter, with the door unlocked, all day. But no harm done... ] The current authorised method closest in spirit to what GlobalSign were doing back in 2010 is 3.2.2.4.4 (Constructed Email to Domain Contact). This method actually doesn't tell them to prevent this particular mishap (machines clicking links), so perhaps that should be corrected.
  - kenniskrag 6y ago
    shouldn't be GET request idempotent?
    - CodesInChaos 6y ago
      GET requests should not have any significant side-effects, unfortunately some do not follow that rule. I once read a story of a whole database getting wiped, because a spider "clicked" on every "delete" link. Idempotence is not enough, it only requires at executing a request a second time (with no other changes in between) has no significant effect, the first time is allowed to have a significant effect. PUT requests are the typical example.
    - 35fbe7d3d5b9 6y ago
      Hopping up on my hobby-horse :) No. An idempotent operation is an operation that can be applied any number of times without a change after the initial invocation. This means the first GET would fire and change state, but subsequent GETs would not. GET should be nullipotent: it is an operation which can be applied any number of times without any change.
      - tialaramex 6y ago
        Also, this went from being an obscure fact about HTTP that might occasionally bite you to being extremely relevant to production systems with TLS 1.3 (thus some HTTPS and all HTTP/2 and HTTP/3 systems) TLS 1.3's zero round trip resumption by its nature can't be bullet proof against repetition. In toy systems you can defend against this (and you might want to) but in big distributed systems it's going to be possible for an attack to play some HTTP request to your system (perhaps different nodes of it) more than once without you realising. This is obviously unsafe if that HTTP request moves $1000 from your bank account to somebody else's bank account (now they have $1000 extra), and on the other hand obviously safe if the HTTP request is just for the Favicon of Hacker News (now they have another identical copy of the encrypted data) but there's also lots of grey area in between. Translating this human understanding into a rule for machines to follow is the exercise where security holes can occur. The safe option is to just never allow 0RTT resumption (as a client or as a server, either can safely refuse to have any part in this) but in pursuit of performance you can expect other choices to be made.
- bombcar 6y ago
  I've never understood how virus scanners don't trigger those click to do something emails ...

londons_explore 6y ago

During a migration from one email system to another, it wouldn't be unusual for some virus scanner product to click every link in every email... Or alternatively, when searching their inbox for "SSL certificate" they found the verification email and clicked the link as a quick way to get to the homepage of whichever company they used last time for their certificate.

comex 6y ago
Or they searched for SSL certificate, found the email, and didn’t notice the date. Perhaps it was marked unread, given that the email verification was never completed in 2010. They thought it was something they needed to do, and did it.
tialaramex 6y ago
It's definitely plausible that the historic URLs which caused this are vulnerable to just being opened automatically by a machine (such as a "virus scanner"). The right fix here is that the URL leads to a simple POST form where you confirm you want the certificate issued. Tools like virus scanners don't fill out forms. We know that by the time the Ten Blessed Methods were coming into existence CAs were discovering that they had numerous cases where an order would be successfully "validated" by contact with a human, but without any human actually doing anything. Email links "clicked" by automated systems, a system that checks you've uploaded a file to your web server treats the 404 error it gets as an acceptable response showing the file was uploaded, several hilarious goofs. [ The irony, for those playing along at home, is that we don't know of any incidents where this was used for an attack. It's like coming home to discover the reason you didn't have your front door key is because you left it on the kitchen counter, with the door unlocked, all day. But no harm done... ] The current authorised method closest in spirit to what GlobalSign were doing back in 2010 is 3.2.2.4.4 (Constructed Email to Domain Contact). This method actually doesn't tell them to prevent this particular mishap (machines clicking links), so perhaps that should be corrected.
- kenniskrag 6y ago
  shouldn't be GET request idempotent?
  - CodesInChaos 6y ago
    GET requests should not have any significant side-effects, unfortunately some do not follow that rule. I once read a story of a whole database getting wiped, because a spider "clicked" on every "delete" link. Idempotence is not enough, it only requires at executing a request a second time (with no other changes in between) has no significant effect, the first time is allowed to have a significant effect. PUT requests are the typical example.
  - 35fbe7d3d5b9 6y ago
    Hopping up on my hobby-horse :) No. An idempotent operation is an operation that can be applied any number of times without a change after the initial invocation. This means the first GET would fire and change state, but subsequent GETs would not. GET should be nullipotent: it is an operation which can be applied any number of times without any change.
    - tialaramex 6y ago
      Also, this went from being an obscure fact about HTTP that might occasionally bite you to being extremely relevant to production systems with TLS 1.3 (thus some HTTPS and all HTTP/2 and HTTP/3 systems) TLS 1.3's zero round trip resumption by its nature can't be bullet proof against repetition. In toy systems you can defend against this (and you might want to) but in big distributed systems it's going to be possible for an attack to play some HTTP request to your system (perhaps different nodes of it) more than once without you realising. This is obviously unsafe if that HTTP request moves $1000 from your bank account to somebody else's bank account (now they have $1000 extra), and on the other hand obviously safe if the HTTP request is just for the Favicon of Hacker News (now they have another identical copy of the encrypted data) but there's also lots of grey area in between. Translating this human understanding into a rule for machines to follow is the exercise where security holes can occur. The safe option is to just never allow 0RTT resumption (as a client or as a server, either can safely refuse to have any part in this) but in pursuit of performance you can expect other choices to be made.
bombcar 6y ago
I've never understood how virus scanners don't trigger those click to do something emails ...