0

This question is NOT a duplicate of question pointed to. There is NOWHERE in mentioned question anything about fact that TLS does not perform hostname verification by itself.

I have ActiveMQ instance and client in Java. Client uses JMSTemplate (org.springframework.jms.core.JmsTemplate) with factory org.apache.activemq.ActiveMQSslConnectionFactory. I have created self-signed certificates and with them trust store and keystore. Trust stores and keystores are read by both programs, I checked it by running both programs with 

-Djavax.net.debug=all

Now my problem is that it seems that client absolutely ignores server hostname verification. Client connects to ActiveMQ using URL:

ssl://localhost:61616?jms.useCompression=true

Now, I tried to check whether everything will fail as expected if I change CN on ActiveMQ's certificate and well, it didn't went well. I changed to CN to e.g:

CN=google.com

or to:

CN=some.random.xxx333aaa.net.pp

but all these values seem to be OK with Java. Also note that there are no SANs (that is subjectAltNames). What more I tried to connect to ActiveMQ with such certificate but installed on different machine, and it seems that it all works well. Which is NOT what I want.

Also: I have finally uninstalled all Java versions and installed 1.8.0_144, using only JDK installer, installed jce_policy-8 in both places (it installs both JRE and JDK), did the same on remote machine too.

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
Jędrzej Dudkiewicz
  • 1,053
  • 8
  • 21
  • 1
    https://stackoverflow.com/a/8546189/2970947 – Elliott Frisch Sep 07 '17 at 20:56
  • You said that client and server are using the same truststore which contains the server certificate. The client will accept the certificate because is "trusted", even is expired, or CN does not correspond with server name. Try to remove it only from client truststore, then connection will fail. It is not an issue – pedrofb Sep 07 '17 at 20:57
  • @pedrofb Wait, are you trying to tell me that just because I trust some CA java accepts any certificate signed by this CA no matter if hostname is valid or not? Wouldn't it be in absolute opposition to what PKI seems to offer? – Jędrzej Dudkiewicz Sep 07 '17 at 21:03
  • @ElliottFrisch Thanks, but it does not answer my question - I just want to know why by default Java doesn't seem to verify hostname. I assume it should, because otherwise people wouldn't look for a way to disable this check. So why doesn't it work in my case? I don't know and that's why I asked. – Jędrzej Dudkiewicz Sep 07 '17 at 21:05
  • No, i didn't say that. You said _"I have created self-signed certificates and with them trust store and keystore."_ I assumed that you are using self-signed certificates, not a CA with child certificates. If you trust a CA, java will accept certificates issued by that CA if they are not expired and hostname match. But if you include a selfsigned certificate in the truststore, it will be accepted – pedrofb Sep 07 '17 at 21:12
  • 1
    @pedrofb I have one master public/private pair + certificate used for signing certificate (with private key) for broker (ActiveMQ) and certificate (also with private key) for client (my Spring based Java program). So trust store for both of them contains master certificate and their respective keystores contain their public keys in certificate and both have their private keys. I created all this using OpenSSL, packed everything into PKCS12 store and imported PKCS12s into JKS. I assume that this prevents scenario that you presented. But I think I found an answer, check my response. – Jędrzej Dudkiewicz Sep 07 '17 at 21:28
  • @ElliotFrisch's link *does* answer your question. Your final sentence reads 'so in fact my question is: how to force hostname verification?', and the link answers it. – user207421 Sep 07 '17 at 22:26
  • @EJP Ok, I deleted this part. So is it still a duplicate? I thought that it is obvious that I'm not looking for a piece of code that does this, but WHY this happens in the first place. – Jędrzej Dudkiewicz Sep 07 '17 at 22:29
  • It is a duplicate of the question you asked. Editing your question to remove the evidence of what you asked does not impress. The fact that the duplicate shows how to do hostname verification manually in TLS strongly implies that TLS doesn't do it by default, wouldn't you say? As to why, the real question is why did you expect it when it isn't mentioned in RFC 2246? The general question of why X doesn't do Y is unanswerable. – user207421 Sep 07 '17 at 22:33
  • What do you mean removing the evidence? I accepted your answer despite not agreeing that question is a duplicate and specifically mentioned, that I removed this part because this was NOT the question that I wanted to ask. Should I ask it again with this part removed? – Jędrzej Dudkiewicz Sep 07 '17 at 22:35
  • You removed the part reading 'so my question really is:'. – user207421 Sep 07 '17 at 22:37
  • Yes, I removed part "so my question really is", since you pointed it out and I realised that in fact it WASN'T my question. Also I do not agree that just because someone shows how to do hostname verification doesn't mean that it isn't done by default. I found this question earlier but I'd never thought that it means that hostname isn't verified. Never the less, to finish it: thanks for an answer, I learned what I needed. – Jędrzej Dudkiewicz Sep 07 '17 at 22:40

2 Answers2

1

Ok, I think I found an answer. Check this link:

https://issues.apache.org/jira/browse/AMQ-5443

and link mentioned in link above:

https://tersesystems.com/2014/03/23/fixing-hostname-verification/

It seems that TLS against what I thought DOES NOT PERFORM HOSTNAME VERIFICATION. This is absolutely stunning, but it seems that this is exactly the case. If no one will provide better answer I'll accept my own answer.

EDIT: Also see this:

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html

and look specifically at this part:

Cipher Suite Choice and Remote Entity Verification The SSL/TLS protocols define a specific series of steps to ensure a protected connection. However, the choice of cipher suite directly affects the type of security that the connection enjoys. For example, if an anonymous cipher suite is selected, then the application has no way to verify the remote peer's identity. If a suite with no encryption is selected, then the privacy of the data cannot be protected. Additionally, the SSL/TLS protocols do not specify that the credentials received must match those that peer might be expected to send. If the connection were somehow redirected to a rogue peer, but the rogue's credentials were acceptable based on the current trust material, then the connection would be considered valid.

When using raw SSLSocket and SSLEngine classes, you should always check the peer's credentials before sending any data. The SSLSocket and SSLEngine classes do not automatically verify that the host name in a URL matches the host name in the peer's credentials. An application could be exploited with URL spoofing if the host name is not verified.

Protocols such as HTTPS (HTTP Over TLS) do require host name verification. Applications can use HostnameVerifier to override the default HTTPS host name rules. See HttpsURLConnection for more information.

Jędrzej Dudkiewicz
  • 1,053
  • 8
  • 21
  • 1
    Your markdown for the link to docs.oracle is broken. Also you should be aware (as sort of hinted by EJP) checking Subject.CN for TLS is becoming obsolete. _For the Web_ https://www.CABforum.org has for several years required all certs to have SubjectAltName (SAN) extension, all major browsers and `HttpsURLConnection` use SAN instead of Subject if present, and recent Chrome _ignores_ Subject and _requires_ SAN. RFC 6125 encourages this for other (name-based) protocols as well, although no one is driving it so forcefully for them. – dave_thompson_085 Sep 08 '17 at 06:49
  • Thank you, that's that kind of comment/answer that I were looking for. – Jędrzej Dudkiewicz Sep 08 '17 at 07:09
1

If you will examine RFC 2246 (TLS) and RFC 2818 (HTTPS) you will discover that hostname verification is part of HTTPS, not part of TLS. In TLS it is entirely up to the application to perform an authorization step.

So in fact my question is: how to force hostname verification?

See this answer.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • 1
    That's basically what I wrote in my answer an hour ago. And why have you marked this question as a duplicate? Does question that you pointed to mentions in any place that hostname verification isn't performed by default? I can't find anything about it in question, answers and comments. – Jędrzej Dudkiewicz Sep 07 '17 at 22:24
  • This answer has the considerable improvement over yours that it cites RFCs instead of tutorials and bug reports. *This answer* provides the information that hostname verification isn't performed by TLS, and normative references. The link answers the question I carefully quoted from what you wrote before I cited it, and was cited for no other purpose. – user207421 Sep 07 '17 at 22:28
  • Ok, answer accepted. Of course you do realise that wall of text in form of RFC is basically not an answer, since reading through whole thing and understanding ramification is a work for a couple of days if not weeks? – Jędrzej Dudkiewicz Sep 07 '17 at 22:32
  • Rubbish. 'Hostname verification is part of HTTPS, not part of TLS'. That's the answer. What I realize is that I have answered the question. Both questions. With citations. A text search for 'hostname verification' yields nothing in RFC 2246 and something in RFC 2818. I haven't posted either a wall of text, and I haven't merely listed RFC numbers either. – user207421 Sep 07 '17 at 22:39
  • "With citations" - sorry, but pointing to RFC is NOT a citation. But yes, you answered it and I accepted it, no question about it. – Jędrzej Dudkiewicz Sep 07 '17 at 22:45
  • @JędrzejDudkiewicz More rubbish. Pointing to a RFC is *exactly* a citation. Look up the meaning of the word, and stop quibbling. Your question has been answered. – user207421 Sep 07 '17 at 23:24
  • Ok, I checked and you're right. I'm not a native speaker and detailed meaning of words sometimes eludes me. Whether I stop quibble or not is completely up to me. – Jędrzej Dudkiewicz Sep 08 '17 at 05:52