Wrong certificate transparency log log_list.json was served from cache about certificate-transparency HOT 8 CLOSED

from certificate-transparency.

We observed that www.gstatic.com resolves to two different IPs (216.58.211.3 & 172.217.22.35), only the latter one having this issue. This means that it seems to sometimes work and sometimes not.

curl -k -H 'Accept-Encoding: gzip' -H 'Host: www.gstatic.com' https://172.217.22.35/ct/log_list/v2/log_list.json > 172
curl -k -H 'Accept-Encoding: gzip' -H 'Host: www.gstatic.com' https://216.58.211.3/ct/log_list/v2/log_list.json > 216

diff 172 216

305,306c305,310
<             "usable": {
<               "timestamp": "2017-10-10T00:38:10Z"
---
>             "readonly": {
>               "timestamp": "2020-05-04T00:00:00Z",
>               "final_tree_head": {
>                 "sha256_root_hash": "CbUBsYFOJysvawCKgFUJZolODUDjWU8bActeOm+itCc=",
>                 "tree_size": 90271162
>               }

This also means that the good one might become bad when it expires at Sat, 09 May 2020 02:55:28 GMT.

from certificate-transparency.

Hey - firstly, apologies, I thought I had posted our plans on here already, but apparently not!

We have been implementing a solution to serve log_list.json and log_list.sig together in a zip file alongside the two existing files. We are in the very final stages of implementing this, and are hoping to have said zip file being published to gstatic by the end of this week.

I'll post back here again and announce it on the ct-policy group once the zip file is live.

Thanks everyone for your patience with this!

from certificate-transparency.

Just for more information, the object that is different it related to DigiCert Log Server 2. We noticed that this log server will soon be retired, hence it is probably related. Perhaps more context here

from certificate-transparency.

Just a little side note for clarity. The constraint of always getting a matching *.sig for the corresponding .json cannot be guaranteed with the "Cache-Control: public, max-age=86400" cache policy. The Accept-Encoding: gzip is just one case where they happened to diverge but there is no guarantee for other cases either.

I guess In practice the easiest solution would be to have a ".sig.json" file which provides both the signature and a unique url for the file that is signed (say containing the hash that was used for signing):

GET /ct/log_list/v2/log_list.sig.json

{
  "signature": "ZWwY9wHJh7DqYKkk3AdJI8owiz1Ibl4kG742IKbq34I+Lrya5rcbEFZ54rL0tzNYVkpOiFil4bmG
KsBz9R0aFsUobF2uig6m/JI9TV7WQvk2rCzmcdRklqbJ3Q/L0YBfQFujl/9zuKzI7K9J4xWlQnSf
onrXe1YxGohL9kHgGlYIortiCbOBY8EPvwWwJGMO8T6d09/SNR7uniMuBpkXhdQm6gi4r595YwxH
HWpScJjeo5raWw3FKPKx4BdcYR8/CL5DurdZRFZT/1TYrAvCdaW4rNPePSnbSgYAVIgNUdSsFkoV
u78s9BxU3p4EXyDmROCJzwZlo95jucy6y6VvS3Y62t7isARO11zB2Fjtkkozn6zq/oKXXVLVRMcc
3tKuiJZsm8WKxYGulhh+YoV6PCfVqwrZY/4E9PMgVzzyai3V24KinrZjukPdhB5xXm0jkiRDfCYv
bVRLVxkC6JFCKe4GTi9Sj6W3WMyXBWLhczYy5iAOMx3MJYiol28cql1rTAzu1Hwh4/qGxLQ9JBzw
qYAkW8utYkkoonQOvIDHbPWwyYtyFyrwXCmhUjFB5cIBGHR8WryLgDYUa6x1s5bpeqRbzAfg5lLF
Jf9yv+puYV/oUYQocXj2uukPgQrS2ZMuvwJZcBf5i0jFwt+UCq9lFQBl8dAn7tR3lhv8Y+BiUO4=",
  "url": "https://www.gstatic.com/ct/log_list/v2/log_list-ZWwY9wHJh7Dq.json"
}

That would require an additional round trip for clients however. To avoid that and keep http cache semantics intact the two would need to be bundled into a single resource but that can be fiddly for the consumers (correctly verifying the signature on a subset of a json).

from certificate-transparency.

Thanks @taknira - is there any rough estimate on when a full fix will be available? We're looking into our options since even the mitigation leads to a signifiant number of users being affected. Before we implement our own distribution of these files, I'd like to understand if waiting is a better idea.

from certificate-transparency.

Hey @taknira, thanks for tackling this. Is there any progress on resolving it fully? We experienced the out of sync issue again yesterday. It did only last for an hour, which is an improvement, but still affected some users!

from certificate-transparency.

Hi everyone,

We are now publishing a zip file containing both the log_list.json and log_list.sig files, which you can find at http://www.gstatic.com/ct/log_list/v2/log_list.zip.

Hopefully this solves the problem!

from certificate-transparency.