Subject: Re: Yet another trusted proxy suggestion

From: Yoav Nir <[email-masked]>
Date: Sun, 1 Dec 2013 11:22:22 +0200

On 30/11/13 5:54 PM, Paul Hoffman wrote:
>
>
> +1. Stephen's response (that a bank can't currently know if there is a 
> TLS proxy in HTTP/1.1) ignores what Yoav said, which is that such a 
> bank could detect that by forcing client auth. Of course they won't do 
> that, but they of course also won't have to because then they would be 
> forced to not have internet banking.
Banks weight costs. They compare the cost of fraud through proxies 
against the cost of not having Internet banking against the cost of 
getting all users of Internet banking to use (bank-issued?) 
certificates. In most of the world, banks have chosen to live with the 
fraud.

If this proposal were to adopted and implemented in browsers and 
proxies, we would be giving banks a fourth choice: Allow Internet 
banking only in the absence of a proxy. Mostly today this means forcing 
people to do their Internet banking at home, or using a phone with a 
cellular internet connection. This adds some inconvenience for the user, 
because they have to either wait until they're home, or force the phone 
to use the cellular connection by disabling wifi. The question is if 
giving them this choice is a good thing or not.

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 2 Dec 2013 08:02:39 +0100

> certificates. In most of the world, banks have chosen to live with the 

You're almost correct, Yoav. Banks don't care about proxies since it's
not where the fraud happens. The fraud happens exclusively in the browser
since there are millions of compromised browsers for just maybe one or
two compromised proxies. And indeed it's just a matter of balancing costs :

  cost of accepting fraud vs cost of blocking it vs cost of closing access.

> giving them this choice is a good thing or not.

It's their problem. I know at least one bank who will not use this because
offering secure access to their users wherever they are is more important
than anything else. The less internet access they have, the more people go
to street agencies, meaning they have to pay people for staying open at
extra hours. In parallel, whatever a compromised proxy could do, a malware
already does in the browser, so by protecting against malware, banks
already protect against compromised proxies. So better accept everyone and
try to offer them some protection than blocking them for no benefit. At
least I'm sure that's how it will be received.

Willy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 02 Dec 2013 08:20:22 +0100

One of the things this conversation brings out is that there are many
use cases even at banks.  The consumer facing use case is quite
different than that of the employee/back office use case.

Eliot

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 2 Dec 2013 08:42:09 +0100

On Mon, Dec 02, 2013 at 08:20:22AM +0100, Eliot Lear wrote:
> use cases even at banks.

Exactly, which is why we must always keep in mind that it is important to
let implementers/users choose what they want and not try to decide for
them what the protocol permits!

> The consumer facing use case is quite

Yes, but they will possibly converge. If properly designed, the protocol
will permit safer proxies and we'll see more offers of filtered browsing
for consumers. There's a lot of demand for this and end users never seem
satisfied with what they have to use at home.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Dec 2013 07:51:16 +0000

>them what the protocol permits!

"Deliver tools, not policies."

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 2 Dec 2013 15:00:35 -0500

"The low tech password verification hash a challenge provided by the server
with the password provided by the client to produce a challenge response.
Suppose we also hash the TLS session key into the response. The server can
now verify the session key is the same at both ends. If it is not, then the
MITM attack is detected."

Stated more generally, by integrating some TLS logic into the HTTP layer,
we can guarantee message integrity and auth and so prevent MITM proxies
from operating in stealth mode.

On Thu, Nov 28, 2013 at 12:55 PM, Christian Huitema <[email-masked]>wrote:

> Yoav wrote:
>
> >  * Deploy client certificates for users. This defeats all TLS proxies,
> >    unless you come up with a proxy that somehow gets the user's private
> >    key. It doesn't get any more "trusted" than that. Very few banks do
> >    this.
>
> There is an alternative, "detect that TLS security has been compromised,
> and
> switch to end-to-end methods." Suppose that we somehow got a new JavaScript
> API that allowed access to some of the TLS data, say looking at the server
> certificate that was used in the connection, or maybe computing a secure
> hash of an input string with the TLS session key.
>
> There are many instances in which HTTP connections carries data that is
> derived from of “shared secret” between client and server. The obvious
> example is the user’s password, but there are other examples. A CAPTCHA,
> for
> example, is effectively a temporary secret between client and server,
> because an attacker will need some time to crack it. Validation pictures
> used by banks are also a form of shared secret.
>
> The low tech password verification hash a challenge provided by the server
> with the password provided by the client to produce a challenge response.
> Suppose we also hash the TLS session key into the response. The server can
> now verify the session key is the same at both ends. If it is not, then the
> MITM attack is detected.
>
> We can do the same with the response to a CAPTCHA. Instead of sending the
> response in the clear, hash it with the session key. Or maybe produce two
> hashes, one with a nonce and another with nonce and session key. Again, if
> the server cannot verify the result, the MITM is detected.
>
> Something similar could be done for verification images. Instead of looking
> for the image by some image identifier, the client looks for the hash of
> the
> image identifier and the session key. If this is not the expected value,
> the
> server returns a “you are being spied upon” image.
>
> Based on that, the server can decide whether to continue the connection, to
> tell the customer to switch to a new Internet service, or maybe to use some
> form of end-to-end encryption for at least some of the data.
>
> -- Christian Huitema
>
>
>
>

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 2 Dec 2013 15:11:43 -0500

Step #1 - Where the browser detects the proxy
=============================================
[If everything is pre-configured, this step may be skipped, but that makes
moving to another network where that particular proxy is not present more
difficult.]
The browser resolves download.adobe.com, and opens a connection to
download.adobe.com port 443. The firewall blocks this. I'm not sure it it's
preferable to block this with some ICMP or with a new TLS alert (so the
firewall completes the 3-way TCP handshake, receives the ClientHello and
only then sends the error), but I'm tending towards the latter. The new TLS
alert is called "mandatory proxy" and contains the URL of that proxy:
https://sslproxy.example.com:443 <https://sslproxy.example.com/>

Yoav,

Why not consider extending WPAD for proxy detection?

Thanks,

Peter

On Thu, Nov 28, 2013 at 2:51 AM, Yoav Nir <[email-masked]> wrote:

> Hi,
>
> After receiving some feedback, I'm revising this proposal by removing the
> CDN and CONNECT.
>
>
> Assume there's a user, [email-masked], who uses her computer at work
> to download something from https://download.adobe.com. Her company hasa
> next-generation firewall called sslproxy.example.com. Alice is aware of
> this proxy, but has been told that the proxy is only used for detecting
> malware and blocking time wasters like Farmville and OKBridge. Specifically
> the IT people and her bosses do not have access to the plaintext. This is
> not enforced in any technical way - but Alice trusts the IT department to
> keep their word.
>
> Another thing to note is that there are actually two components to the
> mandatory proxy. There's the proxy, which deals in HTTP(S), and then
> there's the firewall which prevents E2E communications. They may be
> co-located, but then don't have to be.
>
>
> Step #1 - Where the browser detects the proxy
> =============================================
> [If everything is pre-configured, this step may be skipped, but that makes
> moving to another network where that particular proxy is not present more
> difficult.]
> The browser resolves download.adobe.com, and opens a connection to
> download.adobe.com port 443. The firewall blocks this. I'm not sure it
> it's preferable to block this with some ICMP or with a new TLS alert (so
> the firewall completes the 3-way TCP handshake, receives the ClientHello
> and only then sends the error), but I'm tending towards the latter. The new
> TLS alert is called "mandatory proxy" and contains the URL of that proxy:
> https://sslproxy.example.com:443
>
>
> Step #2 - Connecting to the proxy
> =================================
>
> The browser consults local policy about whether such a proxy might be
> acceptable, and if so, opens a new TLS connection to the proxy and verifies
> the certificate. This allows adding some clever UX that shows the user what
> device is on-path, and also allows pre-configuring the trusted proxy based
> on name.
> I realize that this is where security will be made or broken. It's
> tempting to solve this with some message like this:
> +-----------------------------------------------------------------------+
> | Warning: an HTTPS proxy was detected on the path to                   |
> | download.adobe.com.  The proxy is identified as _sslproxy.example.com_ |
> | |
> | This proxy will be able to read all traffic, including any passwords, |
> | credit card numbers, and personal information. Do not proceed unless  |
> | you trust this proxy.                                                 |
> | |
> |  +-----------------------+  +--------------------------+ +--------+  |
> |  | Trust this proxy once |  | Trust this proxy forever |  | Cancel |  |
> |  +-----------------------+  +--------------------------+ +--------+  |
> +-----------------------------------------------------------------------+
>
> In its favor, it's more clear-cut than certificate warnings that are
> always vague because most certificate errors are misconfiguration rather
> than a real attack. OTOH that "Trust this proxy forever" button is really
> tempting, because it makes the Internet work, as opposed to it being
> blocked. You can send the users off to the browser settings with a complex
> task to perform. This will both give the user time to think if it's really
> OK, and will make wifi providers for places like restaurants and airports
> think twice before deploying this kind of thing.
>
>
> Step #3 - Connecting to the real server
> =======================================
> The browser sends requests through the proxy (in HTTP/1 notation: "GET
> https://download.adobe.com"). The proxy tries to connects and does
> whatever verification it is configured to do. We might need some HTTP error
> status codes to indicate SSL failure.
>
>
> Step #4 - Path information
> ==========================
> As there may be multiple proxies on path, requests and responses go
> through the series of nodes. We should note that things like flow control
> are hop-by-hop, so the SETTINGS frame is not forwarded, but is hop-by-hop.
> We would also like to have some information for both client and server.
> Here's my suggestion for this:
>
> ClientInfo structure:
>  - certificate chain sent by the client (if any)
>  - ciphersuite used
>  - this)proxy certificate chain.
>  - subject (or SKID) of received server (or next proxy) certificate
>
> ServerInfo structure:
>  - certificate chain sent by the server (or another proxy)
>  - ciphersuite used
>  - subject (or SKID) or (this) proxy certificate
>
> Each proxy sends a ClientInfo structure to the server. This could be done
> as a POST to a /.well-known URI or as a new special frame. I prefer the
> latter, but I don't know how well that will sit with several proxies trying
> to push the same resource to the server.
> Each proxy also sends a ServerInfo structure to the client. Again, this
> could be a pushed resource or a special frame. Same concern applies.
>
> Step #5 - Conclusion
> =====================
> At the end of this, both client and server can construct the chain of
> certificate chains and the ciphersuite used in each leg of the trip. This
> allows each of them to make policy decisions about whether the certificates
> on the path are all trusted, and whether the ciphersuites are good enough.
> It also allows the user to show some nifty UI that shows the series of
> proxies on the way.
>
> An advantage for proxy vendors is that this allows the removal of two
> limitations that MitM proxies currently have:
>
> 1. The missing EV indications - by sending the actual certificate chain
>    to the user, the browser could verify that an EV indication is
>    appropriate (subject to browser policy). It would be strange to have
>    both an indication of extended validation and an indication of an
>    HTTPS proxy, but sometimes weird things make sense.
> 2. Missing support for client authentication - by sending the client
>    certificate from the client-side proxy to the server, the server can
>    (at an application level) assign a user identity to the session. It
>    should be noted that this requires the server to trust the proxy for
>    this to work. It might be enough that the client trusts the proxy,
>    but it might not be.
>
>
> TLS is not changed by this proposal except for the alert, but HTTPS is.
>
> I'd love to hear more comments on this. If there's interest I could write
> it up in a draft, but having been burned twice, I'd like to know there's
> interest first.
>
> Yoav
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 02 Dec 2013 20:27:58 +0000

WPAD is frankly not up to the task.

There are too many places where something can go wrong.  DNS lookup 
issues, DHCP issues, deployment of correct PAC script etc etc etc.

Ideally it would be great if a client could be told it was intercepted 
by a proxy, so change behaviour accordingly.

One of the biggest problems with intercepting to a proxy is the client 
thinks it's talking direct to the origin server.  This creates problems 
for auth to proxy, number of connections opened, and other things.

But many customers want to intercept to the proxy because there are no 
bulletproof ways to get ALL clients to specifically use the proxy.

Adrien

------ Original Message ------
From: "Peter Lepeska" <[email-masked]>
To: "Yoav Nir" <[email-masked]>
Cc: "HTTP Group" <[email-masked]>
Sent: 3/12/2013 9:11:43 a.m.
Subject: Re: Yet another trusted proxy suggestion
>[If everything is pre-configured, this step may be skipped, but that 
>makes moving to another network where that particular proxy is not 
>present more difficult.]
>it's preferable to block this with some ICMP or with a new TLS alert 
>(so the firewall completes the 3-way TCP handshake, receives the 
>ClientHello and only then sends the error), but I'm tending towards the 
>latter. The new TLS alert is called "mandatory proxy" and contains the 
>URL of that proxy: https://sslproxy.example.com:443
>
>Yoav,
>
>>After receiving some feedback, I'm revising this proposal by removing 
>>the CDN and CONNECT.
>>
>>
>>Assume there's a user, [email-masked], who uses her computer at 
>>work to download something from https://download.adobe.com. Her 
>>company hasa next-generation firewall called sslproxy.example.com. 
>>Alice is aware of this proxy, but has been told that the proxy is only 
>>used for detecting malware and blocking time wasters like Farmville 
>>and OKBridge. Specifically the IT people and her bosses do not have 
>>access to the plaintext. This is not enforced in any technical way - 
>>but Alice trusts the IT department to keep their word.
>>
>>[If everything is pre-configured, this step may be skipped, but that 
>>makes moving to another network where that particular proxy is not 
>>present more difficult.]
>>it's preferable to block this with some ICMP or with a new TLS alert 
>>(so the firewall completes the 3-way TCP handshake, receives the 
>>ClientHello and only then sends the error), but I'm tending towards 
>>the latter. The new TLS alert is called "mandatory proxy" and contains 
>>the URL of that proxy: https://sslproxy.example.com:443
>>
>>
>>acceptable, and if so, opens a new TLS connection to the proxy and 
>>verifies the certificate. This allows adding some clever UX that shows 
>>the user what device is on-path, and also allows pre-configuring the 
>>trusted proxy based on name.
>>| you trust this proxy.                                                
>>  |
>>always vague because most certificate errors are misconfiguration 
>>rather than a real attack. OTOH that "Trust this proxy forever" button 
>>is really tempting, because it makes the Internet work, as opposed to 
>>it being blocked. You can send the users off to the browser settings 
>>with a complex task to perform. This will both give the user time to 
>>think if it's really OK, and will make wifi providers for places like 
>>restaurants and airports think twice before deploying this kind of 
>>thing.
>>
>>
>>whatever verification it is configured to do. We might need some HTTP 
>>error status codes to indicate SSL failure.
>>
>>
>>through the series of nodes. We should note that things like flow 
>>control are hop-by-hop, so the SETTINGS frame is not forwarded, but is 
>>hop-by-hop. We would also like to have some information for both 
>>client and server. Here's my suggestion for this:
>>
>>ClientInfo structure:
>>Each proxy sends a ClientInfo structure to the server. This could be 
>>done as a POST to a /.well-known URI or as a new special frame. I 
>>prefer the latter, but I don't know how well that will sit with 
>>several proxies trying to push the same resource to the server.
>>Each proxy also sends a ServerInfo structure to the client. Again, 
>>this could be a pushed resource or a special frame. Same concern 
>>applies.
>>
>>Step #5 - Conclusion
>>=====================
>>certificate chains and the ciphersuite used in each leg of the trip. 
>>This allows each of them to make policy decisions about whether the 
>>certificates on the path are all trusted, and whether the ciphersuites 
>>are good enough. It also allows the user to show some nifty UI that 
>>shows the series of proxies on the way.
>>
>>I'd love to hear more comments on this. If there's interest I could 
>>write it up in a draft, but having been burned twice, I'd like to know 
>>there's interest first.
>>
>>Yoav
>>
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Dec 2013 20:30:43 +0000

> from operating in stealth mode.

Anyone know if RFC 5705 support made it into the W3C WebCrypto
API spec and/or implementations?

S.