#12152 closed enhancement (fixed)
Provide hostname with SNI when using https
| Reported by: | francois.lacombe | Owned by: | Don-vip |
|---|---|---|---|
| Priority: | normal | Milestone: | 15.12 |
| Component: | Core | Version: | |
| Keywords: | https, sni, api | Cc: |
Description
Hi,
JOSM is providing a very useful ability to connect to https API services.
I'm currently using a custom instance with a host requiring SNI when connecting with HTTPS.
https://fr.wikipedia.org/wiki/Server_Name_Indication
Since JOSM isn't sending this piece of information, the server is rejecting the connection with a 403 return code.
Is it possible to add this to the https stack please?
Attachments (0)
Change History (10)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
| Keywords: | java8 added |
|---|
comment:3 by , 9 years ago
OK I got from François enough information to test.
The connection with his https/SNI server API is refused by Apache with HTTP 403 + error body as follows:
Forbidden
You dont have permission to access XXX/api/capabilities on this server.
Reason: The client software did not provide a hostname using Server Name Indication (SNI), which is required to access this server.
Apache/2.4.10 (Debian) Server at XXX Port 443
comment:4 by , 9 years ago
It's relatively easy to setup a test instance redirecting to OSM api when needed.
What's the issue with poor SNI support in Java? It's either there or not working, but why must it be disabled?
comment:5 by , 9 years ago
| Keywords: | java8 removed |
|---|---|
| Milestone: | → 15.12 |
| Owner: | changed from to |
| Status: | new → assigned |
So here's the situation.
We received bug report #9875 in which a user receives with Java 7:
javax.net.ssl.SSLProtocolException: handshake alert: unrecognized_name
when accessing https://raw.githubusercontent.com/bastik/mapcss-tools/osm/mapnik2mapcss/osm-results/mapnik.zip
Java effectively supports SNI on client side since version 7, but fails when it receives a warning from a misconfigured Apache server.
So I disabled SNI in r6946 + r6950, but you can enable SNI by yourself with this advanced JOSM property: jdk.tls.disableSNIExtension=false.
There is a low-level workaround here.
I tried to access François' server with Oracle JDK7u80 and JDK8u66 and it works fine.
It works fine also with JOSM server, OSM API and Github.
It must have been a poor Github configuration that has been solved since, so I'm re-enabling SNI by default.
comment:7 by , 9 years ago
Reading #9875 I could say "I said it" :-)
Actually the fact that Java ignores nearly all good practices of network connections and protocols is really disturbing.
If #9875 get's an issue again the solution would be to try SNI first and open connection IP based as a second try.
I think the "unknown name" comes for fallback addresses. And that's not really a misconfiguration in my eyes. Java raises(raised?) an warning to error level which is simply wrong behaviour, as the CA check should be ultimate and not such a warning.
comment:10 by , 7 years ago
Nice to see it
Moving from my own self-signed CA to Let's encrypt solved many issues I may had before.
Anyway, It's good news to see Java fixing such bugs
Sni support had been disabled before because of poor java support. We can see if the situation is better now with Java 8. Can you please share your URL with us? By email if needed..