eclipse-paho / eclipse-paho/paho.mqtt.java
No longer able to connect via SSL using IPv6 address in 1.2.1+ (Contains non-LDH ASCII characters)
- Dominant language
- Java
- Stars
- 2.3k
- Forks
- 919
- PR merge metrics
- No merged PRs in 30d
Description
- [+] Bug exists Release Version 1.2.1 ( Master Branch)
- [?] Bug exists Release Version 1.2.2 ( Master Branch)
- [?] Bug exists in MQTTv3 Client on Snapshot Version 1.2.3-SNAPSHOT (Develop Branch)
- [?] Bug exists in MQTTv5 Client on Snapshot Version 1.2.3-SNAPSHOT (Develop Branch)
After upgrading the paho mqttv3 client from 1.2.0 to 1.2.1, when connecting using ssl://[IPv6-Address] , the client is unable to connect to the server. e.g. when connecting with `ssl://[fd80::160:192:168:162:128]:6006` as the host, the client returns the following error:
```Caused by: MqttException (0) - java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:38)
at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:736)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: Contains non-LDH ASCII characters
at java.net.IDN.toASCIIInternal(IDN.java:296)
at java.net.IDN.toASCII(IDN.java:122)
at javax.net.ssl.SNIHostName.(SNIHostName.java:99)
at org.eclipse.paho.client.mqttv3.internal.SSLNetworkModule.start(SSLNetworkModule.java:139)
at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:722)
... 1 more
```
The client is able to connect without issues if the IPv6 DNS name is used instead of it's address, and an IPv6 address is able to connect if it connects without SSL. An IPv4 address is able to connect with SSL.
This used to be possible in 1.2.0, and I believe it was changed from this commit:
https://github.com/eclipse/paho.mqtt.java/commit/0a2f69f8748166d257c27fdaf20e262c098af5fb#diff-754ba1d62b1bb4cf8c883edfb223333d
, where the host was added as a SNIHostName in SSLNetworkModule.start. It appears that the IPv6 address format fails being converted to ASCIIInternal, most likely because of the colons in the address.
Was this functionality intentionally removed in 1.2.1, and if so was there a reason why? As a result of this change the client is no longer able to provide IPv6 address testing for our application. I haven't been able to test with 1.2.2 yet however the changelog does not show any related updates.
Contributor guide
Assessment
This issue has not been assessed yet.