[Security] TLS Certificates Verification
stpeter at stpeter.im
Tue Aug 19 17:56:33 CDT 2008
Jonathan Dickinson wrote:
> Verifying the TLS certificates is half the problem. If we used an
> Intermediate CA the CA would have to deal with aunt tillies
> misplacing their certificates. This bears a huge problem.
Yes, anything that requires security-ignorant end users to manage keys
(or do anything that requires even a bare cognizance of security
concepts) can be problematic.
> If we wanted to use a IC we could try using an OTP over E2E.
> User would visit clients.xmpp.net/lost and enter their JID.
The client can do this for you over XMPP, no? Is there any reason to
visit a web page here? How does the security-ignorant user know which
website to visit? How do we know they won't be phished? Do they know how
to verify that the certificate provided via https is legit? Etc. Dumb
users are dumb and we can't solve that problem with protocols. :)
> Clients.xmpp.net would establish an E2E session with them and provide
> an OTP. They would copy and paste the OTP (probably quite huge) into
> the next page and be issued a new certificate.
> But that breaks if the client's password has been compromised. Maybe
> a 'tough luck, be more responsible' approach could be taken: no
> certificates for miscreants. Really, I have no idea how this would be
If your account credentials have been compromised, you're in deep
trouble. Use stronger credentials in the future.
> As for verifying the certificates. Using streams in streams and
> starttls has the allure that some clients may support this method
> somewhat non-intuitively. However, you may find that most of those
> clients would need to be updated to pay special attention to
> revocation lists.
Quite possibly, yes.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080819/f2527857/attachment.bin
More information about the Security