rahvee / cbcrypt Goto Github PK

The client will DNS lookup server by hostname, and connect to it. SslStream.AuthenticateAsClient will require the server to present a valid certificate before any traffic goes across the connection. Which is before CBCrypt even starts doing anything.

Something you don't see, because SslStream conveniently abstracts it away for you, is the process of comparing hostname against the server cert. This is http://www.ietf.org/rfc/rfc2818.txt Section 3.1 and the mono implementation is at https://github.com/mono/mono/blob/master/mcs/class/Mono.Security/Mono.Security.Protocol.Tls.Handshake.Client/TlsServerCertificate.cs#L337

SslStream makes the server cert available to the client as SslStream.RemoteCertificate. Unfortunately, the code to perform the check is not available - which means we have no convenient way of applying the server name check against the server cert and CBCryptHostId - unless the hostname used in DNS lookup exactly matches CBCryptHostId. The mono method referenced above is a mono-specific private method and generally not accessible. As far as I know, Microsoft has not yet released the relevant code. Someday we'll have to port that code or something. Until that happens, the only way we can be sure the CBCryptHostId would match the cert - is if the CBCryptHostId exactly matches the hostname that was used by DNS. So in the present version, we are making that a requirement.

The new question that arises is the bootstrap - Imagine an admin creates a new server, that does not yet have a valid SSL cert and does not yet know its own name. They've got to login for the first time in order to set the SSL cert and CBCryptHostId to something meaningful. The situation of CBCryptHostId mismatching hostname should be handled the same as SSL server invalid cert. That is to say - In the bootstrap situation, the user must have already been prompted about SSL server invalid cert. Let that prompt double as passing for the CBCryptHostId mismatch. But if the SSL cert was good, and CBCryptHostId mismatches, then the user still needs to be prompted about the mismatch. Whatever the server announces as its CBCryptHostId, that value must be used by CBCrypt in order to login. And yet, reasonable precautions must be taken by the client, to reject any CBCryptHostId that might somehow belong to some other server. The end result is:

Upon first launch, the server should randomly generate a UUID for CBCryptHostId, just as the server randomly generates a self-signed SSL cert. When the admin logs in for the first time, they'll have to accept the invalid SSL cert, and therefore the mismatching CBCryptHostId. When the admin uploads a real valid cert, they can at that time, set a valid CBCryptHostId that matches the server hostname. It is important to know that all passwords will be invalidated by changing the CBCryptHostId. So when the admin changes the CBCryptHostId, that one admin will be the only user able to login henceforth - and must reset other users' passwords in order for them to login. It is intended that setting a valid SSL cert and corresponding CBCryptHostId should be the first thing the admin does upon creating a new server.