It could be that a CA does have a problem with signing a cert that can be used 
to sign other certs that would potentially be mishandled by a non-technical 
group allowing certs that appear to have a trust chain back to the CA whereas 
the CA hasn't really verified anything about those downstream signings.

Iain.

--
Iain R. Learmonth MBCS
Electronics Research Group
School of Engineering
University of Aberdeen
Kings College
Aberdeen
AB24 3UE

Tel: +44 1224 27 2799

The University of Aberdeen is a charity registered in Scotland No.SCO13683

________________________________________
From: perpass <[email protected]> on behalf of Eric Burger 
<[email protected]>
Sent: 25 November 2013 12:46
To: perpass
Subject: Re: [perpass] CDNs as wiretaps [Unauthenticated,       ephemeral 
keying in HTTP/1.0 without TLS]

Is it physically possible to tell the difference between a CDN and a MITM? IMHO 
the only way of doing this is if the authentication token presented by the CDN 
saying it represents the source is if that token is issued (signed) by the 
source.

In theory, no problem. X.509 chains have no problem with Symantec issuing a 
certificate to foo (the source) and foo issuing a certificate on foo’s behalf 
to bar (the CDN).

In reality, foo is buying service from bar *because* they are not in the IT 
business. They want bar to handle all of the “technical stuff.”

If we can make this easy, we can break the CDN = MITM connection.

On Nov 17, 2013, at 2:00 PM, Brian E Carpenter <[email protected]> 
wrote:

>
> On 17/11/2013 22:25, Learmonth, Iain Ross wrote:
>>>> Also, to completely contradict that point, facebook with https enabled 
>>>> still uses a CDN, so the theory that https prevents CDNs from working is 
>>>> apparently wrong anyway.
>>
>>> I said "possibly" because I wasn't sure. Maybe somebody can explain
>> how it works and how the associated trust model works?
>>
>> The CDN has one TLS connection from the client to the CDN and another from 
>> the CDN to the server, it sees everything in plaintext. A CA signs the CDNs 
>> TLS server certificate so that it can still be accepted by browsers. 
>> Depending on the CA, different verifications of ownership may be made.
>>
>> This does raise the issue that these CDNs, which may be managing many large 
>> services, would be a great place to tap the wires. Maybe we should be 
>> discouraging them?
>
> Yep, that's my concern about the trust model (also after redaing Ted Lemon's 
> response).
>
> All I know is that some site I have decided to trust has redirected me
> to content on a third-party site, which presents an apparently valid cert.
> I don't understand why I should trust that third-party site.
>
>  Brian
> _______________________________________________
> perpass mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/perpass


_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass

Reply via email to