HTTPS mutual authentication alpha release - please test

[Nick Owen]

Hadmut Danisch wrote:
> Mmmh, I'd have two questions about this:
> 
> 
> - It seems that you are not defending against an attack, but trying to
>   protect the user against his own ignorance. The user ignores the
>   warning label, so you want to replace it with a bigger warning
>   label. But the bigger warning label doesn't contain any news or more
>   information, or any protection that the smaller label doesn't
>   provide. It's just that the bigger warning label is bigger (or more
>   red, or more alerting letters...), hoping to wake the user up?

Feedback on the UI would be particularly helpful.  I think it goes a bit
beyond warning labels in that it should be a very familiar site and when
it goes away, the warning is a shock, much like SSH when the server key
has changed.  I estimate it would take about 5 minutes to test this
online.  Directions are in the forums on sourceforge.

> 
>   But user ignorance is not a new type of attack. If the user pays
>   attention to the browser warnings, then I don't see what advantage
>   WIKD should have. Inventing new protocols and complexity, and
>   trusting an additional party without good reason and reasonable
>   advantage is never a good idea in security.

I agree that user ignorance is not a new attack.  We just saw a problem
and wanted to attack the problem.  Users do not pay attention to the
warnings. I think that is widely accepted, though I don't have any
references at hand.  I don't think of it as a new protocol, rather a
check on an old protocol that is having some problems.

Perhaps a clarification is in order.  While WiKID is well-suited to a
service bureau model, I suspect that most people would want it behind
their own firewall.  They can update the certificate at any time.  There
is no third-party to trust and if you want to look at the code, you may
as it is open.
> 
> - The authorized owner must be able to replace the server certificate
>   with a new one at any time, e.g. when the secret key has been lost
>   or compromised.
> 
>   case 1:  If it is not possible to update the hash stored at WIKID,
>   how would the authorized owner ever be able to replace the
>   compromised key with a new one? Wouldn't this force him into
>   continuing in using the compromised key?

As noted above, the key can be changed.
> 
>   case 2: If it is possible to update the hash stored at WIKID, and if
>   the attacker was already able to register a bogus certificate at an
>   official CA, why shouldn't he be able to update the certificate at
>   WIKID as well? In what way is WIKID's certificate verification
>   procedure more reliable than the one of the "trusted CAs" ?

We're not really addressing the situation where the attacker has stolen
a valid private cert, but where an attacker is using some social
engineering trick to fool the user with a MITM site. Thus, we believe
there is value in providing another way to validate to the user that
they are going to the correct site.

Nick

> 
> 
> Hadmut
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> 

-- 
Nick Owen
WiKID Systems, Inc.
404.962.8983 (desk)
404.542.9453 (cell)
http://www.wikidsystems.com
At last, two-factor authentication, without the hassle factor
Now open source: http://sourceforge.net/projects/wikid-twofactor/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com