You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed the commits regarding the certificate updates. Certificate pinning is an outdated technique and should be avoided. With proper CAA records in combination with Certificate transparency logs pinning can be avoided.
lastpass.com does have CAA records. It looks like you could further lock it down by adding CAA records to sub-domains, which would only allow globalsign to be used for lastpass.com
$ doggo CAA lastpass.com @9.9.9.9
NAME TYPE CLASS TTL ADDRESS NAMESERVER
lastpass.com. CAA IN 300s 0 issue "amazon.com" 9.9.9.9:53
lastpass.com. CAA IN 300s 0 issue "globalsign.com" 9.9.9.9:53
lastpass.com. CAA IN 300s 0 iodef 9.9.9.9:53
"mailto:domain@lastpass.com"
lastpass.com. CAA IN 300s 0 issue "digicert.com" 9.9.9.9:53
Please consider removing the certificate pinning code to avoid downstream users having to compile things from source every time the certificates are rotated and their package manangers have not caught up.
The text was updated successfully, but these errors were encountered:
I noticed the commits regarding the certificate updates. Certificate pinning is an outdated technique and should be avoided. With proper CAA records in combination with Certificate transparency logs pinning can be avoided.
lastpass.com does have CAA records. It looks like you could further lock it down by adding CAA records to sub-domains, which would only allow globalsign to be used for lastpass.com
The ct logs are visible here https://crt.sh/?q=lastpass.com
Please consider removing the certificate pinning code to avoid downstream users having to compile things from source every time the certificates are rotated and their package manangers have not caught up.
The text was updated successfully, but these errors were encountered: