3 ms·
$ echo | openssl s_client -connect www.instagram.com:443 2>/dev/null | openssl x509 -noout -dates notBefore=Apr 14 00:00:00 2015 GMT notAfter=Dec 31 12:
by res0nat0r 11y ago
$ echo | openssl s_client -connect www.instagram.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Apr 14 00:00:00 2015 GMT
notAfter=Dec 31 12:00:00 2015 GMT
AWS bucket creds are not the same thing as SSL certs and were most likely specific to only relevant s3 buckets which are totally separate from any load balancers.
- ryanlol 11y agoI never claimed that AWS bucket creds were the same thing as SSL certs.
- res0nat0r 11y agoThen rotating their SSL keys shouldn't be relevant.
- tck42 11y agoUnless I'm misunderstanding, it's relevant because this researcher was able to access (from the blog): -- SSL certificates and private keys, including both instagram.com and *.instagram.com If this researcher was able to access it via not much more than a hole that was _already reported multiple times_, then I think it's not a stretch to think that [many?] other less honest parties could (and in my opinion most likely do) already have it. If it was me, even if it's definitely only a single researcher who got access (and it doesn't sound to me like they know for sure - but regardless), something _that_ sensitive would have to be rotated anyways. If it was someone outside the teams that strictly require access to it operationaly, I'd rotate it, let alone outside the company.