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

Dear Henry,

Since I am not able to edit the wiki, I have prepared two pdf documents:
one for the above discussion about integrity and the second is about
redirection. I could not find/discover any problem with redirection on web
and in the literature. In the document I try to give some information about
http redirection. I hope that you can find some new information. Most of
them are well-known details.

regards
yunus


On Fri, Feb 1, 2013 at 2:27 PM, Henry Story <henry.story@bblfish.net> wrote:

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