Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Why HTTPS is not web security
Search:   Version française
o Skills & Expertise
o Consulting
o Installation & Configuration
o Security monitoring
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Technical assistance
o Training courses
o Agenda
o Past events
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Techno-watch
o Hervé Schauer
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
o Press review
o Press releases
o Publications
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Why HTTPS is not web security   

by Yann Berthier (07/05/2001)

Why HTTPS is not web security ...

First, a bit of background ...

A few days ago, we were auditing the architecture of an extranet platform for a

Among many funny things, we found an application server directly accessible
from the Internet.

This application server use a proprietary http server - well, that's what the
vendor say.

Ok, so we asked the main responsible of the platform about this server who
answered something like 'but it's secure, it uses SSL'

Well, so we asked the responsible of this particular application who answered
something like 'but it's secure, it uses SSL'

Here we asked one of the main architect of this product about the security of
the application server and he answered ... guess what :)

So to summarize : we have a (not audited) application server using a (not
audited) proprietary http server from an editor right on the Internet, and when
we talk about security the credo is 'it uses SSL'.

Wow, I am fully reassured :) 

As a side note, Denis Ducamp has written a very good tip to explain the needs
of reverse-proxies in front of application servers. The tip is available here :
http://www.hsc.fr/ressources/tips/pourquoi-relais-inverse.html in french. I'm
sure he will translate it to english. Denis ? Ok no, not Denis ;-) But someone else will do it, for sure :) 

This tip is about just that : to show what SSL cannot solve for you. It is not
a criticism of SSL nor to say that SSL serves no purposes. Indeed SSL has many
important usages, which can contribute strongly to the security of your

But it can't protect your application servers against badly written CGIs ...

Disclaimer: the standard disclaimers apply here, you should not ... blah ...
educational purpose only ... blah.

So, let's begin ...

You have installed you're new application server on your public DMZ, full of
bells and whistles, but you know you're safe because it uses SSL ;-) . That's
what said your vendor software "We do security, we use SSL"

So now you sit and relax. Err, should you ?

Let's talk with our https server:

% nc www 443

HTTP/1.1 400 Bad Request
Date: Fri, 20 Apr 2001 10:13:33 GMT
Server: Apache/1.3.19
Connection: close
Content-Type: text/html; charset=iso-8859-1

<TITLE>400 Bad Request</TITLE>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Reason: You're speaking plain HTTP to an SSL-enabled server port.<BR>
Instead use the HTTPS scheme to access this URL, please.<BR>
<BLOCKQUOTE>Hint: <A HREF="https://www.hsc.fr:443/"><B>https://www.hsc.fr:443/</B></A></BLOCKQUOTE><P>

Ok, it does not understand our request, that's what it says.

Nevermind, by using openssl we can talk SSL:

% openssl s_client -connect itesec:443

depth=0 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Webserver team/CN=www.hsc.fr/Email=webmaster@hsc.fr
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Webserver team/CN=www.hsc.fr/Email=webmaster@hsc.fr
verify error:num=27:certificate not trusted
verify return:1
depth=0 /C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Webserver team/CN=www.hsc.fr/Email=webmaster@hsc.fr
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate chain
 0 s:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Webserver team/CN=www.hsc.fr/Email=webmaster@hsc.fr
   i:/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Certificate Authority/CN=HSC CA/Email=ca@hsc.fr
Server certificate
subject=/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Webserver team/CN=www.hsc.fr/Email=webmaster@hsc.fr
issuer=/C=FR/ST=Ile-de-France/L=Levallois-Perret/O=Herv\xE9 Schauer Consultants (HSC)/OU=Certificate Authority/CN=HSC CA/Email=ca@hsc.fr
No client certificate CA names sent
SSL handshake has read 1718 bytes and written 320 bytes
New, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA
Server public key is 1024 bit
    Protocol  : TLSv1
    Cipher    : EDH-RSA-DES-CBC3-SHA
    Session-ID: 4171579184866CBD21C72A10DF473C7D13A1ABAE06917B38398A9C2652471467
    Master-Key: 34BCDADA2310DDF8CC7F2FBEAE3E95CD2DC94B72B55E7F9C9219E7A918F64705F07539113F111A2DAB21689E4C706C45
    Key-Arg   : None
    Start Time: 988101045
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

HTTP/1.1 200 OK
Date: Tue, 24 Apr 2001 08:30:58 GMT
Server: Apache/1.3.19
Last-Modified: Mon, 29 May 2000 12:52:15 GMT
ETag: "3c1b8-1214-393267ff"
Accept-Ranges: bytes
Content-Length: 4628
Connection: close
Content-Type: text/html; charset=iso-8859-1


The https server has now understood our request. We made a HEAD request, we got
a positive answer. 

Now I will use stunnel to redirect the connections to my localhost port 8080 to
my 'secure' application server port 443:

% ./stunnel -c -d 8080 -r www:443

Imagine I want to send 2050 'A' to my server, just to see, in case of ... :

% perl -e 'print "GET /cgi-bin/login?user=blah&password=","A"x2050," HTTP/1.0\n\n"' | nc localhost 8080

And imagine the web developers have restricted the length of the password field
in the html form, but don't check it in the application logic ...

... Gotcha !

And now what ? Nothing more. By using stunnel I can know launch vulnerability
scanners against our https server to find vulnerable CGIs, and to try to
exploit possible buffer overflows.

SSL has bought us nothing regarding security here, except a false sense of
security, which is bad. Even worse, it gives our potential attacker a big win :
as the flow is encrypted, the attack will run unnoticed by the IDSs.

So the moral is, before claiming security because of the use of SSL, vendors
should do their homeworks, because bad boys do theirs. Have a look at Bugtraq
to see what I mean ...

For a presentation of monkey-in-the-middle attacks against certificate
authentication with SSL, see:

Last modified on 12 November 2003 at 13:55:01 CET - webmaster@hsc.fr
Information on this server - © 1989-2003 Hervé Schauer Consultants