Re: The TLS hammer and resource integrity

I'm very familiar with intermediaries, seeing as I develop one.
I'll be considering reverse proxies to be the equivalent of the server
endpoint for this conversation... because that is what they are!

It should be the user's choice about what level of security is *available*
between themselves and the first endpoint that they trust to be the entity
they're contacting. It could also be the servers, but, imho, only if you're
negotiating *up* to more secure.

In the case that I'm talking about, the malicious intermediary first must
be trusted as the endpoint to which the client is connecting.  Assuming you
can verify a cert, in the case where the client has chosen to use TLS, at
the least the communications channel between the client and the entity that
has proven themselves to be the entity in question via the cert is
trustable with whatever level of trust we have in the cert itself. The cert
trust stuff, as least far as I know, is also outside the purview of this
wg, despite being very interesting as well.

If you're using an explicit proxy (that being the only kind you can use
with TLS unless someone has installed new root certs and compromised your
endpoint), you are delegating trust to that proxy. The alternative is
simply to not use a proxy, or to not trust that proxy with any encryption
material that renders the data stream in the clear.
-=R

On Wed, Mar 28, 2012 at 2:41 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 29/03/2012 12:43 a.m., Roberto Peon wrote:
>
>> Ensuring security of the endpoints is probably outside the purvue of the
>> WG, however interesting it is.
>>
>> That being said,  we should probably assume that the hosts aren't
>> compromised because otherwise it really doesn't matter what we do.
>>
>> Our task is thus to somehow secure the communications channel. If you
>> make SSL implementation optional on the server side, you suffer from a
>> downgrade attack whereby an intermediary (potentially malicious), denies
>> you all security on the communications channel.
>> If this decision is made, it must be made by the client for the
>> client<->intermediary connection.
>>
>
> This argument holds no water with intermediaries involved (legit or
> otherwise). Remember that intermediary plays the role of both client AND
> server simultaneously.  Sure the client can determine the strength of
> client<->intermediary security level. But then the intermediary has equal
> power to determine the weakness of intermediary<->server hop. Oops,
> malicious intermediary just downgraded the end-to-end security using the
> very control you gave the client. When the control is all one-sided (client
> OR server determining things) downgrade is easy.
>
> It would be better for both security and integrity to allow both ends to
> prescribe their requirements. If either client or server is unable to
> comply with the others requirements TLS can't be used on that hop. Client
> must find another route in order to meet their policy needs. Very
> Expensive, but adds better assurity of real end-to-end security in
> comparison with trying to use TLS to bridge a weak intermediary node.
>  Even with that strictest of strict security measures a malicious
> intermediary able to negotiate strong TLS with both ends can create a weak
> hop between the apparently secure ends.
>
> The final solution boils down to a web of trust at a hop-by-hop level down
> the whole chain. How-to is up for grabs.
>
> AYJ
>
>