Am 21.06.2011 20:38, schrieb Alban Diquet:
> Yes, strange isn't it ?
> I guess it doesn't matter for 99% of the SSL clients, but for what I'm
> doing (a SSL scanner) it's kind of annoying.
> Well it's probably not going to change anytime soon, but now I want to
> know what's going on.
>
> > > When sending a Client Hello message that's larger than 270
> bytes (not sure
> > > what the exact limit is, 255 maybe?), lots of servers on the
> internet don't
> > > send back any Server Hello, but keep the connection open, so
> my client ends
> > > up returning a timeout.
> > > It's really weird, has anyone seen that behavior ?
> > > You can get to a 275 byte client hello for example by using
> OpenSSL 1.0.0.d
> > > with a TLS1 hello, all the cipher suites explicitly enabled
> > > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> > >
> >
> > Is that session ID still valid on the server when this happens?
> > Is it a session ID that the server issued to your client?
>
> I can reproduce this problem, perhaps it is an issue with the load
> balancers that terminate TLS at many large-scale HTTPS-enabled sites.
>
> For facebook, try:
>
> $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1
> -reconnect -connect 69.171.224.40:443 <http://69.171.224.40:443>
>
> The above hangs on the reconnect client hello, while:
>
> $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1
> -reconnect -connect 69.171.224.40:443 <http://69.171.224.40:443>
>
> yields:
>
It may actually be worth connecting the respective system administrator(s).
Finally you are not just wasting your system's rescources. You are also
wasting theirs.
We don't know what kind of resources you are wasting. It will most
likely only be a file descriptor
on the other side (hopefully for a service like facebook they have
plenty of these :-).
If you are triggering more resource hungry effects (memory, CPU cycles)
while you
see no response, you might have found a DoS on their side.
Best regards,
Lutz
