Ryan Sleevi wrote: > > I would say that the vast majority of servers deployed on the Internet > using commonly publicly trusted CAs have more than one chain to choose from > - often dependent on the installed trust anchors - but the servers may > simply not be aware of it, and relying on clients to do the needful (for > example, with AIA fetching). The delta of sites that don't work in Firefox > (when SHA-1 is disabled) compared to Chrome (when SHA-1 is disabled) > illustrate this - as Chrome performs the AIA fetching to find the > alternative SHA-256 paths, while Firefox does not, and requires the server > supply them.
AIA-fetching is a security disaster waiting to happen, it's insecure and irresponsible. While it may be a browser's every day business to aggressively follow each and every URL received over insecure communication channels (plaintext HTTP), download the stuff and try hard to execute it without the slightest amount of risk management (i.e. perform dangerous stuff millions of time to make demonstrations of SWEET32 and attacks on RC4-bias possible), such behaviour is not what the typical programmatic client or server will do (let alone should do). Some users might have a hope that clicking a bookmarked https-URL from a freshly launched web browser would save them from their browser performing arbitrary requests for attackers. Well, if a browser performs AIA-fetching / AIA-chasing, then it is betraying its user, because the AIA-URL received in the ServerCertificate TLS handshake message is not authenticated until _after_ successful verification of the digital signature of that server certificate (at which point AIA-fetching has become unnecessary). If Chrome really does AIA-fetching (*shudder*), how can it be disabled? -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
