Lets assume there is a server and a client and you want to connect those two. Server has a self-signed certificate, and prior to establishing the connection for the first time (enrollment) the server creates a client-certificate, and a one-time-password for the specific client. (initiated on server)

The admin has both machines in front of him, and then types the one-time-password into the client (assume secure transportation of the token to the client). The client then connects to the server (https) and on success, it identifies with the one-time-password. The server then sends the client-certificate to the client.

The insecurity is in the moment of the first connection. As the client does not know the certificate of the server (and it is selfsigned), someone could hijack the connection and redirect the client to a "bad server" and send the one-time-password to that one without even knowing. (Intranet should be most likely fine, the real danger is when this is done over the internet)

There is a way to fix this completely: not only give the client a one-time-password, but also the fingerprint of the server-certificate. Unfortunately this cannot be done in this scenario, and I can only transfer 4 to maybe 6 or 8 byte for the purpose of validating the certificate.

I know this does not establish complete security, but I guess it is better than no check , right? How easy would it be for an attacker, to create a certificate that has the right url and matches .. say the first 4-8 characters of the fingerprint. Is the is there a way to get it more secure with only 4-8 byte?

2 Answers 2


A theoretical solution is to do a first connection with TLS-SRP. This is SSL, but with a special cipher suite which does not use any certificate; instead, the client and server are authenticated to each other with regards to the knowledge of a common "password"; this even tolerates low-entropy passwords because it is inherently immune to offline dictionary attacks. Within this initial connection, the server should transmit a copy of its "normal" certificate, to be used for further connections. This strategy is used in some cases for pairing Bluetooth devices.

Unfortunately, not all SSL/TLS libraries know SRP. GnuTLS does.

If you can get the first 8 true bytes of the fingerprint (not 8 hexadecimal characters), then this can be enough. Generating a fake certificate which matches the first 8 bytes (i.e. 64 bits) of the fingerprint is technologically doable, but expensive (think a few hundreds of PC running for some months).

  • Thanks, this SRP sounds really good, im gonna look into that. Not true bytes, but 8 characters in base62 (only signs and numbers, should be readable token) which should result in 11 hex-chars or 44bit. Maybe even 12 hex-chars/48bit if base64 is possible.
    – Flo
    Commented Jan 10, 2013 at 14:48
  • 48 bits seems too low for comfort. This is in the zone which is in reach of dedicated amateurs; and it is small enough to allow for various precomputation-based optimizations (e.g. rainbow tables). Commented Jan 10, 2013 at 15:11
  • Jea. Have no idea how hard bruteforce-creating certificates until 48bits of fingerprint match is, but even if 2^48 does sound quite big, it still doesnt feel super secure. But SRP seems to be exactly the right thing for this. :)
    – Flo
    Commented Jan 10, 2013 at 15:46
  • To bruteforce-creating such a certificate, you just make one, then tweak the "signature" field until the fingerprint is right. This field comes last, so you only have to fiddle with one 64-byte block of SHA-1 or SHA-256, and that's very efficient (say 2^30 tries per second with a few big GPU). It breaks the self-signature, but nobody verifies it anyway. If the attacker wants to maintain the signature, it is harder since he has to change some extension in the certificate and recompute the signature each time, so he will be down to a few dozens of thousands of tries per second (and per PC). Commented Jan 10, 2013 at 16:14

The server should not create the client certificate, the client should create the certificate and send the private key to the server through the SSL channel you described. In the situation you describe, the attacker can pretend to be the server (whom the client does not know since the cert is self signed) and then take the password to make the request to the server. The attacker can then keep the private key and forward it to the user and neither the server or the user is aware of a problem.

If instead the client makes the certificate and sends the public key to the server and signs the public key with their private key, then the attacker can still intercept the password and send their own public key, however the client would be unable to connect and the intrusion is detected. This doesn't work if the attacker is able to persistently pretend to be the server however as they can hide the fact that the client isn't connecting to the real server.

  • But you still cant verify if the server is the server, so the client registers with the fake server, and then the fake server could act as a client and register with the real server. Not sending over the clientcertificate sounds good, but the problematic situation is before any of this happens.
    – Flo
    Commented Jan 10, 2013 at 14:38
  • @Flo - yes, if the attacker can persistently impersonate the server, then you are up a creek with my approach to as it would never be revealed to the client that they weren't talking with the real server. However if they ever did get through to the real server, my scheme goes one step further because it ensures that a real connection could not be eves dropped on. The original scheme can end up with the server and client and attacker all knowing the client's private key which means it will never be detected even if only a portion of traffic is intercepted. Thomas Pornin's answer is the best. Commented Jan 10, 2013 at 14:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .