Re: Trust and provacy problems with draft-loreto-httpbis-explicitly-auth-proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Raphael,

first let me clarify once again: https resources are not affected by the explicitly authenticated proxy
the draft only propose to proxy the http:// resources.

On May 5, 2014, at 2:28 PM, Raphaël Durand <mail@xxxxxxxxxxxxxxxx> wrote:

I've just read the draft draft-loreto-httpbis-explicitly-auth-proxy, and I see a lot of trust and privacy problem in this "Explicit auth proxy".
https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/?include_text=1

The first problem is in the "opt-out" section (3.3).
First, it has to be "opt-in" not "opt-out" (it's called an "explicit auth proxy isn't it ?")
Second, in order to be efficent, a proxy have to be a bottleneck, so user can't get around it.
How can you implement the 3.3 scheme ? Does the proxy becomes transparent ?
So if an user doesn't trust the proxy, he
must pass through anyway ?

No if the user does not trust the proxy (i.e. does not provide consent for proxing http:// uri resources)
his/her traffic won't pass thru the proxy.

and just to say once again: https:// will never pass thru the proxy!


The other problem concern the trust model using CA certificates as described in the 3.1 section.
What sort of certificate need theses proxies ? Does they need a wildcard for the entiere Internet ?

 (and in other part of the document)

   A consent SHOULD
   however be limited to the specific network access (such as APN or
   SSID) and may be limited to a single connection to that access or
   limited in time.

i.e.  binding the proxy to a specific access



"To ensure the trustfulness of proxies, certification authorities validation procedure for issuing proxy certificates should be more rigorous than for issuing normal certificates and may also include technical details and processes relevant for the security assurance."

No, public CA must not sign these certificates. Proxies certificates must be signed by a local CA explicitly trusted by the user.

(here and only here must be the explicit agreement).

of course Could  be a local CA, but that does not work in airports, hotells…. 
Please note that the proxy is NOT automatically trusted based on CA, 
the user has to explicitly provide consent (i.e. trusting the proxy) even if it has a cert signed by a trusted CA.


"6. Security Considerations
"Those resources are protected end-to- end between user agent and origin server as usual."

No they are not, there is a third-party proxy between them.

based on what we have described in the document a Client will never send an https:// resource thru a proxy


The user do not operate it, so he can't trust it.

"Users should also be made aware that the proxy has visibility to the actual content they exchange with Web servers, including personal and sensitive information."
That's the point, and that why HTTP2 must be flawless. Because the average user is never aware of security concern, IETF standards and softwares based on them must to be flawless
and uncompromising.

Such systems was deployed in Lybia and Syria to trap opponents and kill them (or worse).We should not standardize a method used as a weapon of war by some governments.
The strength of a chain depends on its weakest link, do not intentionally add weak links as these proxies.
Such proxies must not exist.The end to end encryption must not be intercepted or compromised.

Best regards.
Raphaël Durand.


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]