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

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.

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.

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

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.

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