![]() With SSH, for instance, clients store the public keys of servers that they’ve connected to. Other key-based authentication protocols (such as SSH) protect against MITM attacks by way of public key pinning built-in to the protocol. Of course, even the most secure authentication protocol is useless if the connection can be compromised by an active MITM attacker. But, it seems that it has done little to protect against an MITM attack where an attacker is able to get his hands on a fake-but-trusted certificate, and we must continue to put our full faith and trust in CA’s, which have a history of letting us down. I applaud the leap that FIDO has made to reduce our reliance on passwords, and to make authentication more secure and less cumbersome for users. Moreover, even if TLS ChannelID is supported by both endpoints, an active MITM attacker could prevent TLS ChannelID from being used by way of a downgrade attack during the ClientHello message. ![]() And, TLS ChannelID has not been widely adopted by most browsers and servers (in fact, the RFC draft proposal expired in 2013). We’ve seen more than a few cases where attackers have been able to obtain fake-but-trusted CA-signed certs. I’m not convinced that this is such a high bar. ![]() ChannelIDs are NOT supported by the browser. able to get a server cert for the actual origin name issued by a valid CA, andī. In Section 6 of the Universal 2nd Factor (U2F) Overview, where MITM attacks are discussed – near the end of the section, it reads: It is still possible to MITM a user's authentication to a site if the MITM isĪ.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |