[atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection

On 21.05.14 9:48 , Robert Kisteleki wrote:
> On 2014.05.21. 9:26, Ondřej Caletka wrote:
>> Hello list,
>>
>> I just observed strange behaviour of one Atlas probe. It was unable to
>> connect to the control server from a corporate network. I suspect that
>> some IDS/IPS appliance detects and drops probe attempt to use port 443
>> for non-TLS traffic*. I've tested it by trying to SSH to control server
>> from within that network and it failed. However, normal SSH to port 22
>> works fine.
>>
>> It would be nice if the probe would be able to try more ways to reach
>> the control server, eg. first attempt on port 443, second on port 22,
>> third on some arbitrary high port number. I know that it would be better
>> to put the probe in front of the firewall/IPS, but this is much more
>> complicated in many corporate networks.
>>
>> *) At least it doesn't do MitM on HTTPs traffic. I've checked that too.
>>
>> Cheers,
>> Ondřej Caletka
> 
> Hello,
> 
> The probe and the infrastructure it connects to are doing mutual
> authentication (every actor has its own key pair for that) over SSH, meaning
> that if there's an appliance meddling with the traffic, the connection will
> fail. That's of course by design.
> 
> We *could* try to fall back to other ports, but reality is that in the vast
> majority of the cases 443 works fine (*), and where it doesn't, other ports
> would very likely be blocked as well. It's difficult to justify the added
> complexity for the marginal benefit.
> 
> Regards,
> Robert
> 
> (*) As far as we know... We are aware of cases where it doesn't.


It seems to me that just trying port 22 if no contact can be made on 443
should be added to the requested features list. The reason being that
probes could then work in places where policy allows 22. However I agree
that the priority should be low considering the small number of cases
this would fix and the likelihood that measurements would be affected by
middle boxes as well.

Daniel