[Security] TLS Certificates Verification

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 20 11:11:11 CDT 2008


Jonathan Schleifer wrote:
> Dirk Meyer <dmeyer at tzi.de> wrote:
> 
>> Yes. If we only have IBB it will be Base64. Jingle will try to use
>> something else but it may not be possible. I see no way around this
>> problem, not matter what encryption we use. ESessions also use Base64,
>> with Jingle-Streams we have at least a chance not to.
> 
> Yeah, but we don't have a stream that is base64 encoded in a stream.
> Anyway, what if the server administrator has banned IBB and I'm behind
> a NAT? Then I'm pretty much boned. 

Not necessarily. There's still SOCKS5 Bytestreams through a proxy, or 
ICE-TCP. Or you could switch to a different server. If a server admin 
does something that prevents e2e encryption and their users care about 
this feature, the users will complain. And even if IBB is blocked we 
could define yet another even simpler in-band method (even "bits of 
binary" as defined in XEP-0231). But of course server admins could block 
that, too. And nothing stops a server admin from blocking ESessions, either!

> And I *DON'T* want IBB on my server
> for Jingle, I never want a video or file transfered in-band! 

Is "I" the server admin or the client user?

I don't see any reason would anyone would ever use IBB for video anyway, 
but is MTI for file transfer in XEP-0234 as a last resort.

>  So when I
> disable IBB Jingle, I also disable encryption. This gives an all or
> nothing situation, which sucks.

In your client you don't disable IBB for everything, you disable it for 
video and file transfer but not e2e streams.

> I suggest to not use IBB, but have something like:
> <message to='foo' type='chat'>
> <body>This message is encrypted. If you see this text, something went
> wrong</body>
> <encryped xmlns='to_be_decided_on'>base64encoded data</encrypted>
> </message>

That's easy for a server admin to block, too.

> That way, we can catch errors like a message was sent to the wrong
> resource, which doesn't support encryption etc.

Well, we could do that in IBB, too:

<message
     from='romeo at montague.net/orchard'
     to='juliet at capulet.com/balcony'
     id='msg1'>
   <body>
     This message is encrypted. If you see this text,
     something went wrong
   </body>
   <data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
     qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
     WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
     IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
     AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
     kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
   </data>
</message>

There's nothing special about ESessions in this regard.

> We already had problems like this when we implemented ESessions in
> Gajim and thus we act a little different than the standard.

Non-standardized ESessions?! I thought it was a stable technology!

;-)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080820/e0b23d05/attachment-0001.bin 


More information about the Security mailing list