Re: Should we employ WebID authentication only with Self-signed certificates?

On 1 Feb 2013, at 13:25, Yunus Durmuş <yunus@yanis.co> wrote:

>  
> Ah I was thinking of a DoS where you try to kill a site by sending a huge number of requests to it.
> This denial of service attack would be a subtle one: as a man in the middle you just do a minimal 
> change to say get a customer to end up being very angry with the site he is connecting to.
>  
> That makes sense.  It would be good to open a security page on the wiki if you want,
> and to add a number of things you think we should be giving some guidance on in the spec.
> 
> I will open the wiki page in a few days, after understanding how things work in the wiki page.

If someone else wants to help pu that wiki page up, that would be helpful.
I don't think it's going to be a one person job.

> 
> Well redirects can redirect between servers right? These may have different levels of security. Or it may be on the same server between http and https. Or TLS renegotiation could happen. Could you work out what all the cases are that could happen and evaluate the security risks?
> 
> A quick google search did not give me any counter example that shows redirects are insecure. However, this issue needs more research since the explanations were rather vague. I'll put it into my todo list.

I did not mean searching on the web, of course :-)

I meant _re_search: ie. starting form first principles of 
what HTTP redirects do, how WebID functions, what 
security is, and then from there working out what the 
possible lines of attack can be. 

> 
> regards
> yunus
> 
> On Fri, Feb 1, 2013 at 12:23 PM, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 1 Feb 2013, at 11:36, Henry Story <henry.story@bblfish.net> wrote:
> 
>> 
>> On 1 Feb 2013, at 11:19, Yunus Durmuş <yunus@yanis.co> wrote:
>> 
>>> Henry, you perfectly summarized everything.
>>> 
>>> I think you need to detail this DoS attack scenario more carefully.
>>> 
>>> I am not sure that it can be a DoS attack. On the wire  if the adversary can change the "Not After" field for instance from 2020 to 2010, in the peer openssl will rise "10 X509_V_ERR_CERT_HAS_EXPIRED: certificate has expired" . In such a case WebID implementation should be aware of possible attack and disregard the   error message.
>> 
>> Why would someone attack a site by faking the creation of certificates with expired certificate
>> date-time stamps? Why not use good time stamps?
> 
> Ah I was thinking of a DoS where you try to kill a site by sending a huge number of requests to it.
> This denial of service attack would be a subtle one: as a man in the middle you just do a minimal 
> change to say get a customer to end up being very angry with the site he is connecting to.
> 
> That makes sense.  It would be good to open a security page on the wiki if you want,
> and to add a number of things you think we should be giving some guidance on in the spec.
> 
> 
>> 
>>> 
>>>  
>>> Now an interesting thing to work on is: are URIs that redirect via a 303 to another document as trustworthy as #URIs? Can you find a way of using a redirect to undermine WebID security?
>>> 
>>> It is hard to prove that nothing can happen in redirection case. However, I do not think that it is an issue if the connection is HTTPS.
>> 
>> Well redirects can redirect between servers right? These may have different levels of security. Or it may be on the same server between http and https. Or TLS renegotiation could happen. Could you work out what all the cases are that could happen and evaluate the security risks?
>> 
>>> 
>>> Best Regards
>>> yunus
>>> 
>>> 
>>> 
>>> On Thu, Jan 31, 2013 at 3:15 PM, Henry Story <henry.story@bblfish.net> wrote:
>>> Thanks for your contribution Yunus, those are interesting points you make.
>>> 
>>> On 31 Jan 2013, at 14:36, Yunus Durmuş <yunus@yanis.co> wrote:
>>> 
>>>> First of all, now I am writing a paper and do not want to stop using WebID. WebID totally fits to my thesis. Do not think that I am trying to find a hole, but I do not want to get a nasty question [ possibly from a postdoc :) ] while I'm in defense. 
>>>> 
>>>> What I mean from integrity check:
>>>> As you know every certificate has a digest at the end which is encrypted with a private key either by Self or CA.
>>>> Self-signed certificate of Alice:  EncprivateOfAlice( sha1(certificate)) 
>>>> CA signed :    EncprivateOfCA( sha1(certificate)) 
>>>> 
>>>> When any peer either a server or client gets a certificate, it checks the digest by opening it with the corresponding public key. If they match then peer trust that there is no change in the certificate after it has been created. I mean there is no man-in-the-middle who has altered the certificate, it is still the same as it has been generated.
>>> 
>>> yes. So this attack is mostly relevant for server certificates, since they do have to pass over
>>> the wire unencrypted, and could be altered the way you suggest.
>>> 
>>>>  
>>>> I do not think it is a problem for WebID since WebID only uses URI field and changing it on the wire has no use. 
>>> 
>>> Also the client certificate could be passed over the TLS connection that was previously set up. 
>>> In which case the attack to change the client certificate could not happen.
>>> 
>>> BUT.  I am not sure in fact if this SHOULD be the case or if it MUST be the case right now.
>>> 
>>> At any rate I think most client are oblivious to this, so only a MUST would solve the problem you point
>>> to below.
>>> 
>>>> However, if I write a code which does not accept certificates due to "Not After " field is pointing a past time, an adversary who aims DoS attack can change this field.
>>> 
>>> I think you need to detail this DoS attack scenario more carefully.
>>> 
>>>> My code does not realize the change since it does not check the digest. My code simply discards the certificate. However, if it were a self-signed certificate, digest would be able to checked.
>>> 
>>> This is an interesting argument in favor of self-signed certificates, for which we did raise ISSUE-54 .
>>>    http://www.w3.org/2005/Incubator/webid/track/issues/54
>>> On the other hand self-signed certificates are much more difficult to generate in the browser.
>>> 
>>> So your argument is the following:
>>>   1. If the certificate is self-signed and valid then certain fields in the certificate MUST be taken seriously as 
>>>      being stated by the author. 
>>>   2. If the certificate is not self signed
>>>       a. if the issuer's key is known, then all fields in the certificate SHOULD be taken seriously, as statement by the issuer about the user. This means that if you don't care about the issuer, you are in position b. which follows
>>>       b. If the issuer key is not known then all fields in the certificate SHOULD be ignored.
>>> 
>>> Perhaps we should improve by putting it logically:
>>> 
>>>    1. The statements made in the certificate are made by the issuer of the certificate 
>>>      ( so in the case of a self signed certificate they are made by the subject)
>>>    2. One can verify that the issuer made the statements in the certificate if one has the issuers public key.
>>>      ( in the self-signed case this comes imediately )
>>> 
>>>    3. Should one trust what is in the certificate?
>>>        Well that depends on whether you trust the issuer. 
>>>        • In the case of a self-signed-certificate your trust will be at all moments equivalent to the trust you have in the subject. So you can always add the information from the certificate to the graph of information about the subject, and can trust it as much as you trust him. 
>>>        • In the case of a certificate signed by someone else you can trust the statments as much as you trust that issuer
>>>      
>>>    But the crux of the matter is: In both cases you can trust statements independently of who affirmed it,  by verifying it.
>>> The WebID Protocol gives you a verification mechanism for the SAN . 
>>> 
>>>> 
>>>> I say, if a certificate is signed by a CA in WebID protocol, the peer should discard validity period, email address, common name etc. Only  the information on the Profile page should be trusted. For instance I am using openssl and openssl checks the Not After/Not Before fields therefore I should ignore the errors related to the validity period.
>>> 
>>> The information from the profile should be trusted only relatively. You can trust statements that are made in
>>> the profile document using a #uri as definitional and so are necessarily true. Nothing else other than the 
>>> document could tell you what they mean. So that is why this functions.
>>> 
>>> Now an interesting thing to work on is: are URIs that redirect via a 303 to another document as trustworthy as #URIs? Can you find a way of using a redirect to undermine WebID security?
>>> 
>>> Henry
>>> 
>>>> 
>>>> Sorry for all these messages.
>>>> 
>>>> 
>>>> Best Regards
>>>> yunus durmus
>>>> 
>>>> 
>>>> On Thu, Jan 31, 2013 at 12:13 PM, Andrei Sambra <andrei.sambra@gmail.com> wrote:
>>>> Hi again,
>>>> 
>>>> On Thu, Jan 31, 2013 at 11:36 AM, Yunus Durmuş <yunus@yanis.co> wrote:
>>>> Thanks for the replies, I will update my code accordingly, I will allow CA issued certificates, too. 
>>>> 
>>>> TLS verifies that certificate owner obtains the corresponding private key.  However, I checked the TLS standard and I see that at least the server certificate is transmitted openly. 
>>>> 
>>>> What exactly do you mean by integrity check? Validating the server certificate or the client certificate? You need to understand that whenever I mentioned CA, I didn't do it because WebID _requires_ a CA, but because issuing new self-signed certificates is very difficult (see impossible) when using the HTML5 KEYGEN element. Using a CA to sign the client certificates is just an implementation detail, it has nothing to do with the WebID spec.
>>>>  
>>>> Without integrity check of the certificate, an adversary can change the fields like Common Name, Valid Before etc. I am aware that WebID has nothing to do with those fields since the main idea is being related to a profile page. But I think the software should be aware that the information on  CA issued certificates might have  been altered. The logic should not depend on the side information which is presented in the certificate.
>>>> 
>>>> You are describing an attack which is valid only when using a PKI. This attack has _nothing_ to do with WebID, since the private key of the client certificate is never exposed to anyone. Please go over the spec one more time and look at how a client certificate is matched against a user profile. It will become very clear why you shouldn't worry about this issue.
>>>>  
>>>> 
>>>> Sorry for mentioning my-profile, it seemed a kind of offensive but I assure you that there was no such intent. I am heavily using my-profile :).
>>>> 
>>>> There was nothing offensive in what you said about MyProfile, so don't worry about it. :-)
>>>>  
>>>> Andrei
>>>> 
>>>> Best Regards
>>>> yunus
>>>> 
>>>> 
>>>> On Thu, Jan 31, 2013 at 10:07 AM, Henry Story <henry.story@bblfish.net> wrote:
>>>> +1 on all that Andrei, said below, with one minor comment.
>>>> 
>>>> On 31 Jan 2013, at 09:58, Andrei Sambra <andrei.sambra@gmail.com> wrote:
>>>> 
>>>>> Hi Yunus, and thanks for showing interest in WebID. I'm responsible for MyProfile so I'll do my best to reassure you about several things.
>>>>> 
>>>>> I think that what you are fearing here is out of scope in the case of WebID. The whole point of WebID-TLS is to avoid having to rely on a PKI (CA), and in turn move towards a web of trust system, similar to GNU PGP. During the WebID TLS authentication, you never need to check the issuer. 
>>>> 
>>>> We still need CAs so that clients can verify the server. This requirement for CAs for server authentication should one
>>>> day no longer be the only option, when DANE is adopted in browsers and eleswhere
>>>> http://datatracker.ietf.org/doc/rfc6394/
>>>> http://datatracker.ietf.org/doc/rfc6698/
>>>> 
>>>>> 
>>>>> The OpenSSL manual states that error 21 means "no signatures could be verified because the chain contains only one certificate and it is not self signed". This is normal behavior, since MyProfile certificates are issued by a local CA with absolutely no intent to validate this CA by anyone, at any given time. However, error 21 does _not_ mean that your client certificate cannot be verified. The only verification that is performed during the TLS handshake is that your certificate's public key matches its private key. So you see, you can't really have a PKI MiM attack here. :-)
>>>>> 
>>>>> I hope I've been as clear as possible. If you still need more information, please look up the WebID spec, for details on its TLS authentication. http://www.w3.org/2005/Incubator/webid/spec/
>>>>> 
>>>>> Best,
>>>>> Andrei
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Jan 30, 2013 at 3:46 PM, Yunus Durmuş <yunus@yanis.co> wrote:
>>>>> Hi,
>>>>> 
>>>>> The integrity of a PKI certificate is checked by the signature of the CA. If the certificate of the CA is missing in the chain then we can use the WebID authentication (if the certificate involves a WebID URI). However, since we do not trust the CA, we cannot trust the signature either.  As a result, we may authenticate a certificate owner by employing WebID authentication, but we cannot be sure of the integrity of the certificate. Does WebID handle integrity in a different way?
>>>>> 
>>>>> Detailed explanation is as follows: 
>>>>> 
>>>>> I am converting EAP-TLS wifi authentication to allow webid authentication and authorization. I use Hostapd opensource software and hostapd uses openssl. 
>>>>> When openssl cannot authenticate a certificate, it calls a "verify_callback" method and in which I place webid authentication. Openssl calls the verify_callback method for every error of a certificate in case we may want to apply different security measures. 
>>>>> Anyway, if the certificate is self-signed, I get error 18 (self-signed error) and continue with Webid.
>>>>> However, if I use a certificate signed by a website, let's say from my-profile.eu, it raises three errors:
>>>>> 27 X509_V_ERR_CERT_UNTRUSTED: certificate not trusted
>>>>> 
>>>>> 
>>>>> the root CA is not marked as trusted for the specified purpose.
>>>>> 
>>>>> 
>>>>> 20 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY: unable to get local issuer certificate
>>>>> the issuer certificate could not be found: this occurs if the issuer certificate of an untrusted certificate cannot be found.
>>>>> 
>>>>> 21 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE: unable to verify the first certificate
>>>>> no signatures could be verified because the chain contains only one certificate and it is not self signed.
>>>>> 
>>>>> Since the signature of the certificate is created by using private key of my-profile.eu and my-profile is not in the certificate chain, openssl warns me about the above problems. Normally, I was ignoring those and keep going with WebID. However, I realized that error #21 can lead to a man-in-the-middle attack since we are not checking the integrity of the certificate.
>>>>> 
>>>>> 
>>>>> Best Regards
>>>>> yunus
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>>> 
>>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/