4 ms·

PayPal appears to be serving revoked certificate. https://crt.sh/?q=+46702bcc869d216e7225cee5ac729ea769a3cf032c8bf0abc47db286b20155f2 https://crt.sh/?q=+46702bc

by buzer 4y ago

PayPal appears to be serving revoked certificate. https://crt.sh/?q=+46702bcc869d216e7225cee5ac729ea769a3cf032c8bf0abc47db286b20155f2 https://crt.sh/?q=+46702bcc869d216e7225cee5ac729ea769a3cf032... Firefox blocks the access to site, I think most of other browsers do not.

tssva 4y ago
"Firefox blocks the access to site, I think most of other browsers do not." www.paypal.com returns a valid certificate. Chromium based browsers redirect to there. Firefox doesn't redirect there unless you first visit www.paypal.com. Once you have visited www.paypal.com in Firefox, paypal.com gets redirected there. This is not my area of technical expertise so why things get redirected one way versus the other I don't know, this is just the behavior I have observed.
- LocalH 4y ago
  I also noticed that even though Firefox would start redirecting to www, I could then delete the www and force it to try to go to https://paypal.com https://paypal.com anyway, at which time I would receive the revocation error. Edit: Figured it out more reproducibly. https://paypal.com https://paypal.com gives the revocation error. https://paypal.com/ https://paypal.com/ redirects to www, although clicking on these links acts the same and tries to use the revoked cert
bugmen0t 4y ago
Why are other browsers allowing access when Firefox is not? Isn’t this a security issue?
- g_p 4y ago
  Yes, to an extent, but given the state of certificate revocation, some might say this is "by design". There are 2 main ways to revoke a certificate - one is by listing it on a certificate revocation list (CRL), whose URL is inside the CA certificate. This means to check the CRL, the client leaks their IP to the CA operator every time they check. The list of revoked certificates can be as long as the list of certificates issued which are still unexpired - that could be a large download, and you'll need to refresh it periodically. A lot of implementations don't bother using CRLs as a result. The alternative is OCSP, where you can query (in real-time) with the CA whether a given certificate is still valid or not. This means you're revealing which certificate you're checking, so you're telling a third party every time you visit a site. Since OCSP is just a way of getting a refreshed signed confirmation the certificate isn't expired, OCSP stapling is an option, where your web server requests a timestamped OCSP statement and serves it to all requesters - they can check the signature on the OCSP response, and know the certificate wasn't revoked at the time of the CA-signed timestamp. OCSP stapling solves the privacy issue of leaking the sites you visit in real time, and also avoids browsers having to fetch a large CRL list regularly. Revocation is a challenge any time you do certificates or signed data - same with JWT/Paseto - in a distributed system a signed bearer token can solve state sync challenges, but then your new state sync challenge is syncing token revocation!

by buzer 4y ago

tssva 4y ago

"Firefox blocks the access to site, I think most of other browsers do not." www.paypal.com returns a valid certificate. Chromium based browsers redirect to there. Firefox doesn't redirect there unless you first visit www.paypal.com. Once you have visited www.paypal.com in Firefox, paypal.com gets redirected there. This is not my area of technical expertise so why things get redirected one way versus the other I don't know, this is just the behavior I have observed.

LocalH 4y ago
I also noticed that even though Firefox would start redirecting to www, I could then delete the www and force it to try to go to https://paypal.com https://paypal.com anyway, at which time I would receive the revocation error. Edit: Figured it out more reproducibly. https://paypal.com https://paypal.com gives the revocation error. https://paypal.com/ https://paypal.com/ redirects to www, although clicking on these links acts the same and tries to use the revoked cert

bugmen0t 4y ago

Why are other browsers allowing access when Firefox is not? Isn’t this a security issue?

g_p 4y ago
Yes, to an extent, but given the state of certificate revocation, some might say this is "by design". There are 2 main ways to revoke a certificate - one is by listing it on a certificate revocation list (CRL), whose URL is inside the CA certificate. This means to check the CRL, the client leaks their IP to the CA operator every time they check. The list of revoked certificates can be as long as the list of certificates issued which are still unexpired - that could be a large download, and you'll need to refresh it periodically. A lot of implementations don't bother using CRLs as a result. The alternative is OCSP, where you can query (in real-time) with the CA whether a given certificate is still valid or not. This means you're revealing which certificate you're checking, so you're telling a third party every time you visit a site. Since OCSP is just a way of getting a refreshed signed confirmation the certificate isn't expired, OCSP stapling is an option, where your web server requests a timestamped OCSP statement and serves it to all requesters - they can check the signature on the OCSP response, and know the certificate wasn't revoked at the time of the CA-signed timestamp. OCSP stapling solves the privacy issue of leaking the sites you visit in real time, and also avoids browsers having to fetch a large CRL list regularly. Revocation is a challenge any time you do certificates or signed data - same with JWT/Paseto - in a distributed system a signed bearer token can solve state sync challenges, but then your new state sync challenge is syncing token revocation!