#1060 Support RFC 7711: PKIX over Secure HTTP (POSH)
Reporter
Thomas L.
Owner
Zash
Created
Updated
Stars
★★★ (4)
Tags
Type-Enhancement
Status-Fixed
Priority-Medium
Component-Community
Thomas L.
on
Description of feature:
"Experience has shown that it is difficult to deploy proper PKIX
certificates for Transport Layer Security (TLS) in multi-tenanted
environments. As a result, domains hosted in such environments often
deploy applications using certificates that identify the hosting
service, not the hosted domain. Such deployments force end users and
peer services to accept a certificate with an improper identifier,
resulting in degraded security. This document defines methods that
make it easier to deploy certificates for proper server identity
checking in non-HTTP application protocols." - https://tools.ietf.org/html/rfc7711
I came across RFC 7711 as the server admin of the abkenar.net XMPP server hosts his Ejabberd instance at conversations.im. Conversations.im uses a certain X.509 root certificate which is not trusted by default.
Obviously RFC 7711 seems to be a solution to this problem: As far as I understood it tells my Prosody server to check the fingerprint at abkenar.net/.well-known/posh/xmpp-client.json and use this hash to verify the certificate which the hosted Ejabberd instance at conversations.im presents. Verification can then succeed.
Motivation:
Unfortunately RFC 7711 seems not to be supported by Prosody, yet. I would appreciate an implementation as verified communication with abkenar.net (and probably more XMPP services) is not possible at this time (assuming you don't want to include and maintain every single tiny root cert, which anyone on this planet issues!).
In general RFC 7711 seems to be a proper solution for every XMPP server admin who's delegating hosting to an external provider but using his own domain).
Description of feature: "Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols." - https://tools.ietf.org/html/rfc7711 I came across RFC 7711 as the server admin of the abkenar.net XMPP server hosts his Ejabberd instance at conversations.im. Conversations.im uses a certain X.509 root certificate which is not trusted by default. Obviously RFC 7711 seems to be a solution to this problem: As far as I understood it tells my Prosody server to check the fingerprint at abkenar.net/.well-known/posh/xmpp-client.json and use this hash to verify the certificate which the hosted Ejabberd instance at conversations.im presents. Verification can then succeed. Motivation: Unfortunately RFC 7711 seems not to be supported by Prosody, yet. I would appreciate an implementation as verified communication with abkenar.net (and probably more XMPP services) is not possible at this time (assuming you don't want to include and maintain every single tiny root cert, which anyone on this planet issues!). In general RFC 7711 seems to be a proper solution for every XMPP server admin who's delegating hosting to an external provider but using his own domain).
https://modules.prosody.im/mod_s2s_auth_posh.html published, started by Tobias ca 2014.
Changes