5 ms·

I'm fairly sure at least some of the "policy violations" that Symantec did were done exactly as a service to their large bank-or-close-enough customers. It's n

by gcp 10y ago

I'm fairly sure at least some of the "policy violations" that Symantec did were done exactly as a service to their large bank-or-close-enough customers. It's not that banks want to switch to a "better" SSL service, it's Symantec being a "better" service for them that got Symantec into trouble. (IIRC, from reading some of the incident reports)

DaiPlusPlus 10y ago
Can you name some specific examples?
- gcp 10y ago
  IIRC several of the mis-issued SHA1 certs.
- iancarroll 10y ago
  Symantec took one of their widely trusted root certificates and declared that it was now "off the reservation", meaning they may choose to not comply with the BRs for its leaf certificates. I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.
  - yuhong 10y ago
    You will notice that was also their SGC root, and one of the oldest roots that browsers trusted.
  - DaiPlusPlus 10y ago
    But how or why was this done as a favour for their banking customers?
    - iancarroll 10y ago
      Banks and companies like First Data were the (sole?) source of exception requests for SHA-1 issuance past the date it was prohibited. Given the G1 root they pulled has an intermediary called "Symantec Trust Services Private SHA1 Root CA", I can make some guesses...
      - agwa 10y ago
        The exception process used by payment processors such as First Data were for SHA-1 certificates chaining to a root that was still publicly-trusted. They couldn't use an off-reservation root because their client devices didn't trust them. The roots that Symantec took off-reservation are regularly issuing SHA-1 certificates to anyone whose check clears. Got $1,699 to spare? https://www.thesslstore.com/symantec/secure-site-pro-sha1-private.aspx https://www.thesslstore.com/symantec/secure-site-pro-sha1-pr...
        ethbro 10y ago
        I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted? Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
        agwa 10y ago
        > I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted? Yes, if a client isn't receiving root store updates it will continue to trust certificates chaining to the off-reservation root. This is why taking previously-trusted roots off-reservation is bad for the ecosystem and would ideally be prohibited. > Side note: Are payment systems required to link to revalidate their roots at any regular intervals? Many payment systems apparently have no automatic update mechanism, so I assume there is no requirement for such.
        ethbro 10y ago
        Wow, the two of those combined with embedded systems with extended lifecycles seem like a recipe for disaster.
        10y ago

by gcp 10y ago

DaiPlusPlus 10y ago

Can you name some specific examples?

gcp 10y ago
IIRC several of the mis-issued SHA1 certs.
iancarroll 10y ago
Symantec took one of their widely trusted root certificates and declared that it was now "off the reservation", meaning they may choose to not comply with the BRs for its leaf certificates. I don't know if they have actively used it to issue SHA-1 certificates, but they certainly could.
- yuhong 10y ago
  You will notice that was also their SGC root, and one of the oldest roots that browsers trusted.
- DaiPlusPlus 10y ago
  But how or why was this done as a favour for their banking customers?
  - iancarroll 10y ago
    Banks and companies like First Data were the (sole?) source of exception requests for SHA-1 issuance past the date it was prohibited. Given the G1 root they pulled has an intermediary called "Symantec Trust Services Private SHA1 Root CA", I can make some guesses...
    - agwa 10y ago
      The exception process used by payment processors such as First Data were for SHA-1 certificates chaining to a root that was still publicly-trusted. They couldn't use an off-reservation root because their client devices didn't trust them. The roots that Symantec took off-reservation are regularly issuing SHA-1 certificates to anyone whose check clears. Got $1,699 to spare? https://www.thesslstore.com/symantec/secure-site-pro-sha1-private.aspx https://www.thesslstore.com/symantec/secure-site-pro-sha1-pr...
      - ethbro 10y ago
        I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted? Side note: Are payment systems required to link to revalidate their roots at any regular intervals?
        agwa 10y ago
        > I may be being a bit dense, but if your client device contains a root that goes off-reservation, how does it ever receive a revocation notice? Doesn't everything that chains to that root via a valid chain still get trusted? Yes, if a client isn't receiving root store updates it will continue to trust certificates chaining to the off-reservation root. This is why taking previously-trusted roots off-reservation is bad for the ecosystem and would ideally be prohibited. > Side note: Are payment systems required to link to revalidate their roots at any regular intervals? Many payment systems apparently have no automatic update mechanism, so I assume there is no requirement for such.
        ethbro 10y ago
        Wow, the two of those combined with embedded systems with extended lifecycles seem like a recipe for disaster.
        10y ago