[Vortex] TLS + SASL auth ?

[milton.yates at loule.info]

First of all, thanks for the quick reply as usual :)

>El jue, 11-05-2006 a las 11:59 +0200, milton.yates at loule.info escribió:
>> Can I use both TLS and SASL? For example by accepting TLS
>> negociations, then SASL negociations? I have not yet tested this, any
>> thoughts on this?
>
>Sure. In fact, it could be considered, at this moment, the optimal way
>to use current TLS+SASL support provided by Vortex, getting both
>features: secure the connection and to authenticate the remote peer.
>
>In short:
>1) Activate the TLS profile, at the listener side, using:
>
>   - vortex_tls_accept_negociation
>
>2) Activate the SASL profile required, let's say CRAM-MD5, using:
>
>   - vortex_sasl_set_cram_md5_validation
>
>   and then:
>
>   - vortex_sasl_accept_negociation (VORTEX_SASL_CRAM_MD5)
>
>3) Here is the point. Set the CRAM-MD5 validation handler to check first
>for the TLS-fixation status for the connection being authenticated,
>using: 
>
>   - vortex_connection_is_tlsficated
>
>and them authenticate as normal.

fine, I was guessing it would work this way... I just have to test it for myself now, thanks :)


>> Another question I have is whether it is possible:
>> - for the TLS connected client to actually GET the server certificate
>> so that he can actually verify the content and validity of the
>> certificate. I did not find anything yet on this in the doc.

>> - for the TLS clients to use their own X509 client certificates, and
>> for the server to be able to receive these cert and do whatever to
>> validate them. This is sort of a TLS certificate-based authentication.
>> Is this planned in any way?
>
>As stated above, all these questions are connected mainly because they
>seeks to solve the authentication and connection security problem.
>Obviously, there are several solutions to perform this. 

Well, not exactly. The second point is indeed a way to authenticate using TLS mecanisms. But the first point is just to know if there is a function the client can call to get the certificate of the server so that he can check whether this certificate is valid or not (understand: the certificate of the server is what the client was expecting - or - verify that the certificate of the server is signed by a trusted authority)
--> this is to prevent man in the middle attacks, where a man in the middle would present to the client a random TLS certificate, and the client would trust him and send its authentication credentials, for example in PLAIN SASL... then the attacker would have gained these credentials.

Bye
Milton.