IceSSL: client side hostname validation with multihomed clients

bluemlblueml Member Marcus BluemlOrganization: T-MobileProject: Telecom Rating Application
Hi All,
I am currently facing the problem that the validation of client side hostnames on the server side (using an IceSSL::CertificateVerifier) fails, when the client connection comes in from a machine with multiple interfaces (I am using Ice 3.4.1 on SLES 10 Linux).

The root cause seems to be the fact that the client side of the socket "randomly" binds to one of the interfaces. In our case it selects an interface that is not assigned to one of our well defined hostnames (defined at deployment time) that are guaranteed to remain stable when applications are moved to other machines.

Technically it should be possible to select a well defined interface on the client side using bind(...) before connecting the socket (I admittedly have tested that on Linux only). This would then enable server side validation against well defined IP addresses.

Currently I do not see any means of cleanly implementing validation of client side hostnames without hacking the codebase, but possibly I have overlooked something.

After some investigation into the codebase, it seems possible to implement "client side binding of endpoints" with limited effort (e.g. analogous to the "--interface" option for UDP based endpoints).

This might also make it possible to automatically validate client side hostnames on the server side (using IceSSL::Instance::verifyPeer), though I must admit that I have not investigated that deeply. This would mean, that hostname validation (on the client side its already available) in both directions would be available "out of the box" without any handcrafted certificate verifier.

In am sure there will be better ideas or even objections from the experts, it would really be helpful if somebody can provide hints how to proceed (if somebody is interested, I can of course provide all patches to the forum).

KR,
Marcus

Comments

  • mesmes CaliforniaAdministrators, ZeroC Staff Mark SpruiellOrganization: ZeroC, Inc.Project: Ice Developer ZeroC Staff
    Hi Marcus,

    The ability to bind to a specific network interface for outgoing connections is not a commonly-requested enhancement (which probably explains why it's not currently supported :) ).

    Also, given the fact that client-side addresses can be spoofed so easily, it never occurred to us to add client address validation in IceSSL. I suppose I can see the usefulness of this in tightly-controlled network environments.

    If you need this feature right away, modifying the TCP/SSH implementations in Ice to support an --interface option (like the one in UDP) would be a reasonable solution.

    Regards,
    Mark
  • bluemlblueml Member Marcus BluemlOrganization: T-MobileProject: Telecom Rating Application
    Hi Mark,
    I thought again on this issue and think it might be advantageous to just add a new configuration variable (e.g. "Ice.Default.Interface") that controls binding behavior (instead of adding "--interface" to the endpoint definition).

    I see following pros:

    (a) fewer classes will be affected, which probably means lower risk to introduce nasty side effects (adding the "--interface" option would mean to pass this information through several classes)
    (b) control is at a central location and will ensure that all outgoing connections will always use the specified interface (no need to specify that on endpoint level)
    (c) a later extension to support "--interface" on endpoint level is still possible (without breaking existing code)

    Any ideas from your side?

    One important question: if I provide this patch, is it possible to merge this change into the official codebase and deliver this with the next official version?

    KR,
    Marcus
Sign In or Register to comment.