One of the factors to take into consideration is that while ssl provides an encrypted tunnle for the client to server connection, it is almost always plain text on either side of that tunnel. Generally this includes while it is being maintained by the server. (store and forward for users off line)
What David is recomending is that if the data needs to be encrypted from one user to anotheer, then the proper place for that encryption to be done is on the client. Another way to look at it is like e-mail. The reason you set up a ssh tunnel to collect pop mail is not to encrypt the data you are transfering, it is to encrypt the authentication process to prevent someone from sniffing your password, and passing themselves off as you, while they send threatening e-mail to the president, or knock down yahoo's web servers. Unless you use some form of encryption on the message itself that can only be decrypted by the intended recipient(s) _Anyone_ at your ISP with admin rights, or on any server storing your e-mail along the way, can read your e-mail. Likewise for Jabber. If you look around, you will find jabber clients on various platforms that will use pgp, gpg, or openpgp to encrypt messages you send, or decrypt messages you recieve. there may be others, but these are relatively common on a variety of platforms. Then again, I could be wrong. -Rusty On Wed, 2002-03-13 at 19:51, David Waite wrote: > I assume you trust both server operators not to look at the sensitive > data, and that you can ensure that the other client is only connecfting > to the remote server via ssl. I'm also assuming all of these servers > have trusted certificates (at least to the local clients and between > servers). Is it acceptable to only have s2s connections allowed to and > from machines that run a ssl-enabled s2s component? If you allow a mixed > environment, you may find that users cannot tell if their conversations > with another user are encrypted or not - either the connection between > servers or the connection from the other server to the remote client > could be unprotected, and the local user would not know. > > This kinda ruins the point of having data encrypted at all - who cares > if the conversation _could_ be safe :-) Thats why most of the proposals > for encryption in Jabber are endpoint-to-endpoint encryption - the two > endpoints do not have a dependancy on the support of an encryption > standard on the servers between them. > > -David Waite > > Bray, Dan wrote: > > > > >I'm building a specialized Jabber client to enable various entities to > >exchange data. The data needs to remain private. I can encrypt the payload > >but there is also a desire to keep the routing secret so I need to transport > >over an SSL socket. I've got this working fine on the client side but am > >now concerned about deliveries that need to go ourside my server. I need > >server to server SSL. > > > >I'd like to work on this and would appreciate some help narrowing down the > >code I need to look at. Whre do I start to look? mio? dialback? At what > >level are the s2s connections managed? > > > >Thanks > > > >Dan Bray > > > > > >_______________________________________________ > >jdev mailing list > >[EMAIL PROTECTED] > >http://mailman.jabber.org/listinfo/jdev > > > > > > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev
signature.asc
Description: This is a digitally signed message part
