I think he's asking if we can recognize if it is realy TLS being
relayed and not another protocol funneled via port 443 to cheat the
CONNECT method of an HTTP proxy.
If so that could turn useful as many services use port 443 (chat,
modified SIP gws that funnel both the SIP and the RTP inside a TCP
connection, etc...) to allow users inside firewalls to connect to
their servers (I used to have the ssh server of a host at home
listening on port 443 to be able to connect to it from inside a
firewalled network cheating the firewall wich alloweed me to use the
http CONNECT method).
I studied the feasability of this a while ago (delaing with a
SIP/"RTP" over TCP client that requested a CONNECT to port 443 to
connect to the GW).
That would require some heuristics being tried on the http dissector
for the stream after the response to the connect CONNECT request to
see what's there and then create a conversation to handoff the
remaining packets of the stream to the relative dissector.
So that means, that instead of handing off to ssl whatever comes after
the CONNECT request we should try some heuristic dissectors that
eventually create a conversation for that TCP stream.
Luis.
On 5/16/06, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
Hi,
You assume that the contents of the http protocol is encrypted, because
you say "-not the contents of course". Actually it's the http protocol
itself that is encrypted. That is why you only see SSL (TLS) packets.
Thanx,
Jaap
On Tue, 16 May 2006, GRL wrote:
> Sorry if I'm asking for an already (perhaps) argument: why isn't
> possible to filter https frames -not the contents of course?
> Thanks.
> Giovanni
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan