[foaf-protocols] Security hole in SSL/TSL

[Peter Williams]

Hmm. I didn't make my main point well.

In foaf+ssl, surely there is no data that follows the ssl handshake.  
For what foaf+ssl claims, the protocol run end when the handshake  
event is given to the socket consumer, it executes is trust model  
(collect a foaf file from webid, impose validity login on cert public  
key,...), and is now complete. I&a is performed, with the benefit that  
lots of other metadata describes the identifier (establish

On Nov 17, 2009, at 1:19 AM, Bruno Harbulotn l<Bruno.Harbulot at manchester.ac.uk 
 >cute wrote:

> Hi Peter,
>
> Peter Williams wrote:
>
>> In foaf+ssl, what do we have?
>> We only rely on the ssl handshake protocol (vs payloads whose  
>> security  typically derives from the proofs of the handshake). It  
>> proves the  user controls a private key. (when a trusted linked  
>> data store add  knowledge to determine the authenticity of the  
>> public keys, facts  about keys support inferences of facts about  
>> webid control and then  personhood).
>> If one uses the "attack" on foaf+ssl to inject content, or spoof  
>> the  source of a payload (that foaf+ssl does not use), are any   
>> vulnerabilities encountered?
>
> With FOAF+SSL, the problems related to re-negotiation are the  
> exactly the same as with X.509 certificates.
>
> If the server makes the assumption that what was sent before the re- 
> negotiated handshake was done by the same client as the one who  
> presented its certificate during that handshake, then the problem  
> arises. Whether that client certificate is verified using a PKI or  
> FOAF doesn't really matter.
>
>
>
>
> This SSL/TLS problem could be addressed at the HTTP layer if the  
> HTTP framework could be notified that such a re-negotiation  
> happened, and thus invalidate the authentication context linked to  
> the request during which the re-negotiated handshake happened.
> As I was suggesting on the TLS list, perhaps a 401 status with 'WWW- 
> Authenticate: Transport' might be useful for this sort of problem;  
> it might also help implement a cleaner behaviour when it comes to  
> optional client-certificate authentication (as opposed to the  
> current required/optional configuration of server sockets, which can  
> sometimes be confusing from the browser point of view).
>
>
> Best wishes,
>
> Bruno.
>
>
>
>