Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

[[e-mail] (Martin Rex)]

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