Comment 1 for bug 925657

Hi,

I just worked on refactoring, simplifying and cleaning up the certificate validation code. It's now much easier to read but it's not fixed with regards to this bug report.

tls_verify_certificate() first uses x509_verify_certificate() to attempt to validate the certificate using OpenSSL and ~/.freerdp/certs as a lookup path. My understanding is that one can add trusted CAs in ~/.freerdp/certs and have that be used with this first technique. Would that be what the first issue was about?

If x509_verify_certificate() fails, we resort to use our equivalent of ssh's known_hosts file. A check is made with the hostname that was given and the fingerprint of the certificate. If they don't match, certificate validation fails. The user can manually accept untrusted certificates for later, as with SSH.

Now when working on this, I noticed that SSH had two different error messages, one for the fingerprint mismatch, and one for the hostname mismatch. I think this is what you are looking for if I understood you correctly.

SSH will show something like this when the hostname does not match:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: POSSIBLE DNS SPOOFING DETECTED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

I can work on adding an additional hostname checking function besides the fingerprint check. I'd just like to make sure:

if I connect to, let's say, freerdp.com using its IP address (173.236.214.234) I'll get a hostname of 173.236.214.234, not freerdp.com. In this case, how do I properly check that hostnames match? The certificate will probably give me a different hostname than the one which was used for connection.

Also, I guess that the known hosts should always store the hostname from the certificate, and not the one given by the user?

Should the IP address be used in this verification process in any way?