[Security] TLS Certificates Verification
stpeter at stpeter.im
Wed Aug 20 08:27:52 CDT 2008
Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> Greg Hudson wrote:
>>> On Tue, 2008-08-19 at 21:56 -0600, Peter Saint-Andre wrote:
>>>> It does? Negotiate a reliable transport, start an XML stream, and
>>>> upgrade the stream to encrypted via STARTTLS, just like we
>>>> currently do for client-to-server streams. How is that enormously
>>>> complex? Granted, the reliable transport might not be raw TCP -- it
>>>> might be a direct or mediated bytestream (XEP-0065), an in-band
>>>> bytestream (XEP-0047), or some other reliable transport. But I
>>>> don't see how that makes the complexity enormous.
>>> If existing TLS libraries can be used for XTLS, then my argument
>>> collapses, since those same libraries are already used for channel
>>> security. I'm skeptical that it will work; perhaps a proof of concept
>>> is in order.
>> I'm all for that. Unfortunately I'm just about the worst coder in the
>> XMPP community, so I need to defer to others. I think Dirk Meyer has
>> been working on this, but I'm not sure how far he's gotten.
> Yes, I have some python code doing this. It is not public yet because
> it needs some cleanup and some more docs. If you want I can upload a
> tgz somewhere. It works very well.
> About in-band bytestreams: I just
> connect the IBB with a unix domain socket. So the TLS lib reads from a
> socket like it is used to be. The difference here is only that the
> implementation must perform different validations (that part is what
> the discussion is about) and that the stream must be connected to one
> remote client. And the client needs to support some server code like
> being the server and answering a <stream> request. But the later is
> similar to link-local messaging. So my implementation simply connects
> the IBB with a unix domain socket and after that the link-local part
> takes over. A client supporting link-local messaging does not need
> much updates.
I mostly agree. I think the main challenge for existing codebases will
be to abstract out the stream handling. Right now stream handling is
probably tied to TCP in a lot of clients, but on this model stream
handling needs to be a bit more abstract so that it can be used for c2s
TCP (and HTTP), link-local, and e2e via in-band bytestreams or some
other reliable transport.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/5762a6b2/attachment.bin
More information about the Security