Hello Marcus, Marcus Moeller schrieb: [...] > We got multiple, balanced targets (so called proxies) in 1st stage. > > client -> loadbalancer with common name -> c2s -> target1 -> s2s -> server2 > client -> loadbalancer with common name -> c2s -> target2 -> s2s -> server2 > . > > Dialback is done against the common name of the load balancer as the > initial request from the client was send to this hostname. The id of > server1 is set to the common name, too. > > So I am still just asking how to prevent dialback.
I don't think that there is any possibility to prevent dialback. Dialback was introduced some years ago to get rid of Spam on the network and to ensure that the sender is the one he claims to be (just like SPF does it for e-mail) - TLS will do that too, so your approach is another good one but as Peter already mentioned on jadmin: Not everyone is using TLS yet and the one who do don't always use the certificates issued by the XMPP-Foundation. I still don't understand your problem with dialback. s2s is only a server-thing where no clients are involved. Does this loadbalancer-thing in your figure above also affect incoming s2s-connections? But if it is loadbalanced, there should still be no problems with dialback. During verification all neccessary informations (sender-, target-domain and Stream-ID) are send over the wire by both entities [0], so there should be no problem for any entity knowing the shared secret to verity the connection. Kind regards, Bernd [0] http://xmpp.org/extensions/xep-0220.html#protocol -- \\\||/// \\ - - // ( @ @ ) -oOo--( )--oOo------------------------------------------------------- Firma Bernd Holzmüller www.tiggersWelt.net [email protected] Mönchstrasse 25 Büro: 07 11 / 550 425-90 70191 Stuttgart Fax: 07 11 / 550 425-99 -- To unsubscribe send a mail to [email protected]
