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

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.



> 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.

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/
>
>