SPDY breaks DNSSec/TLSA because of wrong TLS certificate reusing

[ae...@imirhil.fr]

Hi,

There is some trouble to enable SPDY on a DNSSec/TLSA protected domain.

Context :
    2 domains, a.example.org and b.example.org, 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/proxy for isolation,
       use of CACert for primary content but more friendly/commercial certificat for the
       secondary (stats/static) content to avoid warning…).

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.

In my opinion, 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 my 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.

Regards,
-- 
Aeris

Protect your privacy, encrypt your communication
GPG : EFB74277 ECE4E222
OTR : 5769616D 2D3DAC72
https://café-vie-privée.fr/

[Adam Langley]

On Tue, Dec 30, 2014 at 3:12 PM, <ae...@imirhil.fr> wrote:
> 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.

If a SPDY client implemented TLSA (and I'm not aware of any that do at
the moment) then they would have to take that into account when making
the pooling decision. It's not a fundamental issue.

> In my 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…)

Again, the client, if it implements these features, would need to take
them into account. It's clearly not a fundamental problem because
Chrome implements public-key pinning and SPDY and does what you would
expect—it doesn't pool across pin sets.


Cheers

AGL

[Aeris]

> If a SPDY client implemented TLSA (and I'm not aware of any that do at
> the moment) then they would have to take that into account when making
> the pooling decision. It's not a fundamental issue.

> Again, the client, if it implements these features, would need to take
> them into account. It's clearly not a fundamental problem because
> Chrome implements public-key pinning and SPDY and does what you would
> expect—it doesn't pool across pin sets.

TLSA exists on Firefox through an extension. https://www.dnssec-validator.cz/

And this is why I consider this is not of the responsability of SPDY to do
pooling decision.
A lot of thing *outside* the SPDY client can impact the pool decision.
And so, SPDY must not pool TLS connexion if it can’t be *fully aware* of the
context, witch is impossible, and so must not pooling at all.

If you do pooling the way it currently works, you will create a new
« systemd » TLS, managing all the world of TLS on a single basecode (key
pinning, TLS client certificat, TLSA, custom OCSP responder), instead of doing
only a single simple thing (accelerate HTTP request)…
--
Aeris

Protégez votre vie privée, chiffrez vos communications

[Adam Langley]

On Tue, Dec 30, 2014 at 4:04 PM, Aeris <ae...@imirhil.fr> wrote:
>> If a SPDY client implemented TLSA (and I'm not aware of any that do at
>> the moment) then they would have to take that into account when making
>> the pooling decision. It's not a fundamental issue.
>
>> Again, the client, if it implements these features, would need to take
>> them into account. It's clearly not a fundamental problem because
>> Chrome implements public-key pinning and SPDY and does what you would
>> expect—it doesn't pool across pin sets.
>
> TLSA exists on Firefox through an extension. https://www.dnssec-validator.cz/

It sounds like you're complaining that Firefox doesn't provide to
extensions the hooks needed to control this. That might be the case
but, if so, then you are sending your request to the wrong place I'm
afraid.


Cheers

AGL