shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Merlin <eska...@n0pe.org>
Subject Re: X509Certificate support
Date Sat, 12 Jun 2010 09:14:36 GMT
My current patch is only about TLS mutual authentication.

/Paul


Le 12 juin 2010 à 03:59, Les Hazlewood <lhazlewood@apache.org> a  
écrit :

> Sorry, I forgot to clarify that my last post does not assume the use
> of SSL.  An alternative, which I'm sure is what Paul was talking
> about, is to use X.509 for TLS-based mutual authentication between a
> web server and web browser.  Note that this can be very slow and a
> huge resource hog for the web servers though.
>
> <opinion>
> It's OK for intranet apps, but most public facing webapps won't
> support this due to the performance impact as well as one nasty little
> issue:  it requires browser configuration and often end-user 'know
> how' - most people are insanely confused by this stuff.
>
> Even in intranet environments though, it is often better to support
> things like One Time Passwords and two-factor authentication (FOBs,
> smart cards, etc) because they don't require client-side configuration
> (a potential burden for IT to maintain inside an organization) and can
> even be used (easily) outside of the intranet (think of a remote
> contractor using VPN into a company's dev network).
> </opinion>
>
> Nonetheless, if the community wants TLS-based X.509 support, we should
> definitely support it.
>
> Les
>
> On Fri, Jun 11, 2010 at 5:42 PM, Les Hazlewood  
> <lhazlewood@apache.org> wrote:
>> Hi all,
>>
>> Comparing two public keys does not constitute a valid authentication.
>> X.509 certificates (and the public keys within them) are expected to
>> be publicly distributed, so their content alone should not be
>> considered as a credential.
>>
>> I think I should write a blog article about how to do this  
>> effectively
>> - the very short summary is that there are usually two common ways of
>> doing X.509 authentication:
>>
>> 1.  Using the X.509 certificate alone (nothing else):  The server
>> encrypts something (e.g. a random token) with the public key  
>> contained
>> in the user's X.509 certificate.  That encrypted data is given to the
>> user.  The user decrypts it with their private key (the one
>> corresponding to their public key in the X.509 cert) and gives the
>> decrypted data back to the server.  If the server receives the  
>> correct
>> data, then it knows the identity is authentic since only that user's
>> private key could have decrypted the token successfully.
>>
>> 2.  X.509 certificate and credentials: The user encrypts a credential
>> (password, biometric signature, whatever) with their private key.   
>> The
>> server receives the encrypted credential and decrypts it with the
>> public key in the X.509 certificate.  If the decrypted value matches
>> the one stored in the system, the identity is considered authentic.
>>
>> HTH,
>>
>> Les
>>
>> On Mon, May 24, 2010 at 10:11 AM, Brian Demers <brian.demers@gmail.com 
>> > wrote:
>>> Yeah, the comparing of two public keys confused me (still does  
>>> actually) but
>>> I emailed the apache sshd list of conformation (hasn't hit the  
>>> archive yet,
>>> so no link)
>>>
>>> Anyone else have any thoughts on these realms?
>>>
>>>
>>> On Mon, May 24, 2010 at 12:56 PM, Paul Merlin <eskatos@n0pe.org>  
>>> wrote:
>>>
>>>> Le lundi 24 mai 2010 18:26:39, Brian Demers a écrit :
>>>>> Here is what we have:
>>>>>
>>>> http://github.com/sonatype/security/tree/master/security-realms/security-pu
>>>>> blic-key-realm/
>>>>>
>>>>> Note this just compare two public keys, ( so this assume  
>>>>> something else
>>>> is
>>>>> doing the hand shaking with the private key )
>>>>>
>>>>
>>>> Thanks for sharing Brian.
>>>>
>>>> Some things are similar to my implementation (already attached as  
>>>> a patch
>>>> in
>>>> jira). Looking at PublicKeyWithEquals, it could be related to my  
>>>> second
>>>> matching
>>>> strategy, fingerprint, except that you compare the public key data
>>>> (pk.getEncoded()) and not the certificate data.
>>>>
>>>> Be aware that a KeyPair can be certified several times and so a  
>>>> PublicKey
>>>> can be
>>>> used in several X509Certificate 'instances'.
>>>>
>>>> IOW the ssl engine had the proof that the client own the  
>>>> PrivateKey and
>>>> that
>>>> it's certificate is trusted. You then match only the PublicKey  
>>>> that's
>>>> inside the
>>>> certificate, not the certificate itself.
>>>>
>>>> Use cases leading to a security hole in your implementation will  
>>>> certainly
>>>> by
>>>> awkward and depend a lot on deployment and certification policies  
>>>> but one
>>>> can
>>>> imagine such a scenario.
>>>>
>>>> We could say the very same about my Simple strategy.
>>>>
>>>> /Paul
>>>>
>>>>
>>>>
>>>
>>

Mime
View raw message