KEYP

From ADCPortal Wiki

This extension adds a simple, but secure way to protect against man-in-the-middle attacks against ADC when wrapped with TLS (1.0 or later). It does not require setting up a CA or signing keys, but that is still possible if desired.

The extension introduces a keyprint parameter to the ADCS URI. The keyprint parameter is a hash of the server certificate.

The extension also requires clients to publish their own certificates' keyprint in the KP field in the INF. Assuming one trusts the hub enough not to maliciously change the keyprints en route (a reasonable assumption given the hub's existing position of trust), and given that the connection to the hub has been similarly authenticated (either as above or via a directly downloaded trusted certificate), client-client connections are also protected against attempted man-in-the-middle attacks - without messing around with having to get everyone's certificates signed in advance.

The keyprint parameter consists of a hash name, followed by a forward slash ('/'), followed by the Base32-encoded cyrptographic hash of the certificate.

The hash used shall be SHA256. Other extensions may add other hashes, given sufficient security contemplation.

INF field;

Keyprint replacement behaviour

If a client receives a KP field in an FINF broadcast via a hub it is connected to using ADCS and a trusted key as above (or otherwise), it should be regarded as the valid and correct keyprint for that client's IP/port/hub combination, replacing any earlier keyprint for that IP/port/hub combination.

Keyprint verification

When initiating a TLS handshake with a remote host where the keyprint is known, the client can verify that a man-in-the-middle attack is not occurring by checking if the hash given in the keyprint exactly matches that of the certificate presented during the handshake by the remote host.

Suppose the client is aware of a remote host's keyprint and is in the process of connecting to that host. A certificate substitution attack is in place if the hub presents itself with a certificate that does not match and where the certificate is not the root of the valid signature chain covering the certificate. If the client detects such an attack, the client should abort the connection and notify the user with a message stating, for example, "Crypto error: Detected attempted man-in-the-middle attack, aborting". (This error quite possibly represents a real attempted attack that has been foiled; we may try auto-reconnecting but we should NEVER ignore it, or it will succeed. We may wish to avoid stating the keyprint of the certificate that was actually received.)

Optionally, when receiving a TLS handshake, if the client knows what the remote host's keyprint ought to be, the client could also verify this. However, note that only the initiating side needs to check this for the man-in-the-middle protection to be valid; specifically the hub doesn't need to remember, or even understand, clients' keyprints.

Security Considerations

General

The certificates, including the name fields, are sent in the clear during the initial handshake. Therefore it is recommended to avoid identifying marks in the certificates CommonName fields (for example) that would clearly single them out as being TLS keys used by ADCS:, and the CID field most definitely should not appear. Quite possibly no name fields should appear, or they should be blank.

Client-Hub

The keyprint in the ADCS URI prevents a clandestine man-in-the-middle (certificate substitution) attack on the TLS session with the hub, if and only if the kp parameter hasn't been modified by an attacker.

Suggested countermeasures against this include the following;

• Even if otherwise unprotected, an attacker would likely only have a maximum of one opportunity to make the substitution (by changing the kp parameter when the URL is first sent to the user); if it's changed later, it will be detected. ("Casual first-use" security, as often used in SSH.)

• Checking the fingerprint or transferring the hub URL out-of-band (for example by telephone, or in person) could reveal or thwart man-in-the-middle attacks; something's wrong if you don't have the same URL as the hub operator gives out. (PGP-style "sneakernet" security.)

• We would be protected if the URL were in a file signed by some secure means by a party we have already decided we trust not to change the URLs maliciously. Encryption would not be necessary, only a signature to ensure no untrusted party has modified the KP fields. (A signed hublist, possibly.)

Finally, we would be protected were the hublist/URL retrieved from an https: site signed by a CA we trust not to issue signatures for any domain to someone who doesn't own that domain, and the owner of that domain trusted not to modify the KP fields. (SSL-style security.)

Client-Client

We are, in particular, trusting the hub not to maliciously modify the KP fields sent by the clients through their INF broadcasts. However;

• The hub would gain nothing from swapping the keyprints of its users, as it would not gain anything from mounting a man-in-the-middle attack on its own users that it does not already have the ability to do, as it's the hub; and
• If the client do not trust the hub enough not to maliciously modify the data, why is the client choosing to connect to the hub and transmit the client's IP address through the hub?
• It could be detected by cross-checking with other clients/hubs, as connecting through a malicious hub would clearly show to have a different keyprint to any other hub; therefore any hub doing this would obviously be quickly removed from hublists.

Example

See Also