Re: SSH tunneling/port forwarding and stateful packet inspection

From: steve (steph19731_at_yahoo.com)
Date: 02/27/04 

Date: 26 Feb 2004 15:58:52 -0800

Richard E. Silverman <res@qoxp.net> wrote in message news:<m2eksi4m8o.fsf@darwin.oankali.net>...
> > My terminology is not mixed up. According to my packet trace, because I
> > have reconfigured SSH to run over port 443 the trace shows it as SSL
> > traffic.
>
> You are mistaken. Your packet trace identifies the TCP connection as
> carrying the SSL protocol simply because the destination port is 443,
> which is the well-known port for HTTP over SSL. In other words, your
> tracing tool is not inspecting the contents of the connection, merely
> labelling it on the basis of the destination port -- which in this case is
> misleading because you happen to be running an SSH server on the port
> normally used for HTTPS.

I never said it WAS ssl traffic. I said the trace showed it to be ssl
traffic and I know full well it is not. So cut out the condescending
tone already. I also know it is labeling it as such, which brings me
back to my original point AND leads me to pose my next question - are
there any firewalls that can see and block this type of traffic (and
not based on the previous response to "shut down traffic" based on the
packet carrying "anything that says SSH" - this is plain ridiculous).

>
> > Of course the contents are encrypted. This is my whole conclusion why
> > the stateful packet inspection capabilities of the firewall do not blow
> > it going outbound. Because to it, it is just an SSL packet encapsulating
> > SSH data, which of course is encrypted.
>
> The data are indeed encrypted, but by SSH; there is no SSL connection
> anywhere in this scenario. Also, even if it were not encrypted
> (e.g. select the "none" cipher for the SSH connection), the port-forwarded
> TCP connections would still not be blocked by the firewall, as the
> forwarding is happening at an entirely different level, as I pointed out
> in my last post.

I fail to see where you pinted that out. And when talkimg about
"level" do you mean layers? If so, what layer would that be that - I
would hope it would be on another layer.

Relevant Pages

  • Re: SSH tunneling/port forwarding and stateful packet inspection
    ... According to my packet trace, ... >I have reconfigured SSH to run over port 443 the trace shows it as SSL ... Your packet trace tool just can't tell the ...
    (comp.security.ssh)
  • Re: Cross Realm MIT <-> Windows Close But No Cigar
    ... Info about the two domains and ssh / smbclient test results follows. ... I created some principals and it confirmed the enctype was archfour-hmac: ... debug2: we sent a gssapi-with-mic packet, ...
    (comp.protocols.kerberos)
  • Re: OT: Security....
    ... you can't really spoof IP addresses on SSH sessions. ... You send a SYN packet, ... Normally since you would not get the SYN ACK ... This would work to the spoofers benefit since the machines ...
    (Fedora)
  • Cross Realm MIT <-> Windows Close But No Cigar
    ... Info about the two domains and ssh / smbclient test results follows. ... I created some principals and it confirmed the enctype was archfour-hmac: ... debug2: we sent a gssapi-with-mic packet, ...
    (comp.protocols.kerberos)
  • Re: PuTTY internals
    ... > command line sessions and found that PuTTY appears to be sending each ... PuTTY can certainly be expected to send two SSH messages per ... the next character before sending a packet. ...
    (comp.security.ssh)