Hi,
There is some trouble to enable SPDY on a DNSSec/TLSA protected domain.
Context :
2 domains, a.example.org and b.example.net
Hosted behind the same IP
2 differents TLS certificates, both valid for A and B (eg. *.example.org for both)
Content on A use content of B (eg. domain sharding, virtual server for isolation…).
SPDY (for speed purpose I guess) currently fetch the content for both domains A
and B throught the same socket, without TLS renegociation, because A
certificate is also valid for B domain and contents share the same IP.
But this way, SPDY potentially breaks TLSA validation if B TLSA entry isn’t
valid for the A certificat.
So currently, SPDY usage is not compatible with valid DNSSec/TLSA usage.
SPDY *must not* choose by itself if it can reuse a certificate or not.
2 differents certificates *must* be use if server administrator declare 2
differents certificates, even if the IP is the same and/or one certificate
seems valid for another domain.
Security purpose *must* be a priority on speed purpose.
In this case, SPDY break TLSA, but the current TLS behaviour of SPDY can break
all others client-side usages of TLS (custom OCSP responders, certificate or
key pinning, hardcoded server certificate verification…) in case of the SPDY
« TLS implementation » choices lead to different behaviours or are unaware
of things than official and standard TLS stacks use.
----
What version/revision number of mod_spdy are you using?
https://github.com/eousphoros/mod-spdy
commit ab03b622681feec912d0f46bb284eb2d38b35948
What version of Apache are you using, and on what operating system? (Use
`apache2ctl -v` to check.)
Server version: Apache/2.4.10 (Debian)
Server built: Nov 18 2014 14:21:53
What browser version did you use to access the mod_spdy server? On what
operating system? What flags was the browser invoked with? (For
Chrome/Chromium, go to about:version to check.)
Iceweasel 31.3.0esr-1, Debian Testing
Original issue reported on code.google.com by ae...@imirhil.fr on 28 Dec 2014 at 6:03
Original issue reported on code.google.com by
ae...@imirhil.fron 28 Dec 2014 at 6:03