Does the following data stream look secure to you?

Question

I understand the basic concept of SSL but maybe I am missing the point. Please could someone take a look at the following part of a test log to a server and tell me if it looks secure. My concerns are that although the certificate callback returns "true" you can see that it states under policy status RemoteCertificateNameMismatch.RemoteCertificateChainErrors and mentions untrusted root.

1:07:04 AM: SSL: secure.newsfarm.ams2.highwinds-media.com:   Certificate: E=support@sslusenet.com, CN=*.sslusenet.com, OU=sslusenet.com, O=sslusenet.com, L=Phoenix, S=AZ, C=US
9/7/2012 1:07:04 AM: SSL: secure.newsfarm.ams2.highwinds-media.com:   Policy status: RemoteCertificateNameMismatch, RemoteCertificateChainErrors
9/7/2012 1:07:04 AM: SSL: secure.newsfarm.ams2.highwinds-media.com:   Chain status: UntrustedRoot
9/7/2012 1:07:04 AM: SSL: CertificateCallback returns True
9/7/2012 1:07:04 AM: SSL: secure.newsfarm.ams2.highwinds-media.com:   KeyExchange: RsaKeyX (1024 bits)
9/7/2012 1:07:04 AM: SSL: secure.newsfarm.ams2.highwinds-media.com:   Cipher: Aes128 (128 bits)
9/7/2012 1:07:04 AM: Nntp: < highwinds: 200 Welcome to Virgin Media
9/7/2012 1:07:04 AM: Nntp: > highwinds: AUTHINFO USER bnv *******@binverse.com
9/7/2012 1:07:05 AM: Nntp: < highwinds: 381 PASS required
9/7/2012 1:07:05 AM: Nntp: > highwinds: AUTHINFO PASS ***
9/7/2012 1:07:05 AM: Nntp: < highwinds: 281 Welcome to Binverse.com (No Posting)

Are the security considerations what the callback is checking or is there actually a name mismatch from an untrusted root with chain errors and the callback is just returning "true" anyway regardless?

Answer 1

Although the log files you show are relatively obscure, one can see some fishy things in the first few lines:

• Apparently, the server which was contacted under the name secure.newsfarm.ams2.highwinds-media.com responds by sending a certificate which is meant for *.sslusenet.com, which does not match the server name.

• The UntrustedRoot part is suggestive of a certificate chain which begins with an untrusted root certificate -- i.e., a chain which proves nothing to the client.

So it is like bypassing a security warning on a HTTPS Web site. This is vulnerable to active attackers.

Answer 2

It only matters if the client trusts the root.

Whatever you're using to capture the traffic is not configured to trust the root. But the actual client, which is presumably a web browser, probably does.

If the chain to the root is valid and the root is trusted then the client will consider it trusted.

But your real question: Is the data stream secure?

If you know you put that certificate and key onto that server, and you know that it has not been compromised, then it's secure wether the root is trusted or not.

If you didn't put it there yourself then it's only as secure as your definition of "secure". You need to trust someone else to have set it up securely. A root certificate authority is supposed to give you that assurance. Do you (personally, not the computer configuration) trust that certificate authority?

Answer 3

The log was taken from the error diagnosis inside the client. It checked on rotex and found this:

Would this account for the difference in name : 69.16.160.0/21 Puregig AS11588

Base Record Name IP Reverse Route AS ns2.sslusenet.com a 69.16.163.16 United States (none) 69.16.160.0/21 Puregig AS11588 HIGHWINDS Network Group, Inc.

Why would it still return "true" if there was a problem. If what you say is true then every usenet client that connects to a server is fundamently flawed then in terms of SSL?