TC9 can verify certificates using system certificate store, but there are still few flaws. If there's wincmd.pem and it contains CA used by server's certificate, everything is ok. But if wincmd.pem does not exist, the following happens:
Wrong status icon. Even if certificate is trusted, it shows red open lock and tooltip with "ssl: unverified". But when clicked, message box says "Certificate OK!", which is correct.
When TC gets wrong certificate from server, it does not warn user and continues with login. It even proudly admits to that when user clicks lock icon ("The presented server certificate seems to belong to a different server name!"), but it's too late. It's a major security hole, because if it was MITM attack, bad guys would already have user's credentials.
I also tested if just the existence of wincmd.pem makes a difference, so I tried an empty one (zero-sized file) and it has another problem:
Connection to server with correct certificate works without prompts, which is ok, because certificate was verified using system store. Status icon has closed lock and tooltip "ssl: verified", that's correct too. But message box wrongly claims that "The certificate was not signed by a trusted party (self-signed)!", even though it's signed by CA.
All tests were performed with clean-ini TC and valid certificate from Let's Encrypt CA. For "wrong certificate" tests I simply connected to numeric IP address instead of hostname. While I was at it, I also tried self-signed certificate and it also did not work as it should:
Without wincmd.pem, it was automatically accepted. Status was shown correctly, but again, too late if there was MITM. This is for both correct and wrong hostname.
Last edited by Sob on 2016-07-06, 22:28 UTC, edited 1 time in total.
Well, it might be, I had wincmd.pem for loooong time, so I don't really remember how TC behaved without it. Now I wanted to get rid of it, because it shouldn't be needed any more.
I checked forum and found an older discussion and according to that, your idea was to not bother users with error messages if they did not bother with adding wincmd.pem. Because with no wincmd.pem, there would be no certificate and warning would be shown for every connection. I can't say that I completely agree with that, but it's no longer important.
But now it's a different situation, because certificates of trusted CAs are always available (from system store). So the reason for not bothering users with "unnecessary" errors is gone. Either the server certificate is valid and can be verified, which will happen with all properly configured servers. Or it can't be verified and in that case, user should know about it *before* login data get sent to server.
I only found small inconsistency with new VerifyCerts option, which gives mixed results in following case:
- VerifyCerts=-1
- no wincmd.pem
- server with proper certificate that could be verified using CA from Windows
When connecting:
- there is no warning (ok)
- there is red lock with "ssl:unverified" tooltip (ok)
- info dialog (after clicking lock) says "Certificate OK!" (not completely ok)
In info dialog, TC verifies certificate, even though VerifyCerts=-1 plus no wincmd.pem should mean no verification. On the other hand, it does not hurt anything, so you can probably keep it this way.
IMHO whole VerifyCerts=-1 does not make much sense, I can't see any use case for that (unlike VerifyCerts=-2, which can be useful for portable TC, when you have trusted certificates in wincmd.pem and don't want to trust what's in system store).
