*What steps will reproduce the problem?*
1. Configure a virtual host
2. Configure and generate separate SSL certificates for the 'global' configuration and the vhost configuration
3. Enable mod_websocket
4. Observe the certificate served by mod_websocket when connecting to the vhost
*What is the expected output? What do you see instead?*
The expected output is to be served the vhost-specific certificate, like happens for a regular XMPP connection. Instead, the 'global' certificate is served.
*What version of the product are you using? On what operating system?*
Prosody 0.9.4, Debian 7, installed from official repository
*Please provide any additional information below.*
Serving the global certificate rather than the vhost-specific certificate, will inevitably lead to common name mismatches on multi-vhost setups. This is a serious problem.
MattJ
on
Hi, thanks for the report.
The underlying issue is that the websocket protocol does not support starttls like XMPP connections do. Therefore we do not know which certificate to serve before we start the SSL handshake. LuaSec does not support SNI, which was the solution that HTTPS uses for this issue.
I should note though that in the case of websockets, the websocket host that you connect to has zero effect on the XMPP hosts you can log into. E.g. you can create 'websocket.example.com', anything that has a valid cert, and use it to log into all your XMPP hosts.
In any case, SNI support is desirable. Work has begun on adding it to LuaSec, but when this will be released I cannot say.
Changes
owner MattJ
tagsType-Defect Type-Enhancement Status-Accepted
title SNI support
Zash
on
LuaSec does have SNI support but I'm not sure if it's in a release yet.
Zash
on
I've got a working implementation for net.server_select
It changes various net.server methods by adding a 'sni' argument. Baking this into the existing context argument would have been nicer but how would you do this with a cdata?
Changes
tagStatus-Started
Zash
on
We should settle what API we want for this, in net.server, portmanager
Note: This was the server bits. Serving https or XMPP over TLS might work. HTTPS requests need some additional work in net.connect.
Zash
on
Remaining parts for clients (including HTTP clients) done in 600eee3c4752::6c804b6b2ca2
MattJ
on
Backported to 0.11 in 0.11.7.
Changes
tags Milestone-0.11
MattJ
on
I should clarify that only the client parts were backported (e.g. HTTP requests made through net.http). The server parts are too complex, and will be in the next major release.
*What steps will reproduce the problem?* 1. Configure a virtual host 2. Configure and generate separate SSL certificates for the 'global' configuration and the vhost configuration 3. Enable mod_websocket 4. Observe the certificate served by mod_websocket when connecting to the vhost *What is the expected output? What do you see instead?* The expected output is to be served the vhost-specific certificate, like happens for a regular XMPP connection. Instead, the 'global' certificate is served. *What version of the product are you using? On what operating system?* Prosody 0.9.4, Debian 7, installed from official repository *Please provide any additional information below.* Serving the global certificate rather than the vhost-specific certificate, will inevitably lead to common name mismatches on multi-vhost setups. This is a serious problem.
Hi, thanks for the report. The underlying issue is that the websocket protocol does not support starttls like XMPP connections do. Therefore we do not know which certificate to serve before we start the SSL handshake. LuaSec does not support SNI, which was the solution that HTTPS uses for this issue. I should note though that in the case of websockets, the websocket host that you connect to has zero effect on the XMPP hosts you can log into. E.g. you can create 'websocket.example.com', anything that has a valid cert, and use it to log into all your XMPP hosts. In any case, SNI support is desirable. Work has begun on adding it to LuaSec, but when this will be released I cannot say.
ChangesType-DefectType-Enhancement Status-AcceptedLuaSec does have SNI support but I'm not sure if it's in a release yet.
I've got a working implementation for net.server_select It changes various net.server methods by adding a 'sni' argument. Baking this into the existing context argument would have been nicer but how would you do this with a cdata?
ChangesWe should settle what API we want for this, in net.server, portmanager
It's been many years. Any sign of a fix?
Done in https://hg.prosody.im/trunk/rev/adc0672b700e .. 75d2874502c3 How to configure this is left as an exercise ;) and might change.
ChangesMattJZashNote: This was the server bits. Serving https or XMPP over TLS might work. HTTPS requests need some additional work in net.connect.
Remaining parts for clients (including HTTP clients) done in 600eee3c4752::6c804b6b2ca2
Backported to 0.11 in 0.11.7.
ChangesI should clarify that only the client parts were backported (e.g. HTTP requests made through net.http). The server parts are too complex, and will be in the next major release.