http request sending garbage response when request is sent on SSL port.

[Atul Singhal]

Dear Friends,

I am using Tomcat version 6. In my web application , only SSL port 7443 is being listened.
But, the problem I am facing is:

When I access my web application using URL https://hostname:7443/ ---everything works fine.
But,
When I access my web application using URL http://hostname:7443/ (no https here) . It returns some garbage value.

I am not able to comprehend why it is returng garbage response. Why even it is returning any response for http?

Now, What I am looking for is , if any user , by mistake , use http instead of https, it should redirect to https automatically. Is it possible?

Please note, port should be same in case of redirection as well which is 7443 here.

My server.xml excerpts are like:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

<!--
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- A "Connector" using the shared thread pool-->
<!--
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
-->
<!-- Define a SSL HTTP/1.1 Connector on port 8443
This connector uses the JSSE configuration, when using APR, the
connector should be using the OpenSSL style configuration
described in the APR documentation -->
<!-- GW UI will run on 7443 for non-VSP environment -->
<Connector port="7443" protocol="HTTP/1.1" SSLEnabled="true"
clientAuth="want" truststoreFile="/tmp/xyz.jks" truststorePass="adfs"
maxThreads="150" minSpareThreads="2" maxSpareThreads="5"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" debug="0" scheme="https" secure="true"
sslProtocol="TLS" keystoreFile="/tmp/cert/acb.jks" keystorePass="dfsdf"
ciphers="SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_C


+++++++++++++++++++++++++++++++++++++++++++++++++

Any help is highly appreciated.

[Rob Spoor]

Atul Singhal wrote:When I access my web application using URL https://hostname:7443/ ---everything works fine.
But,
When I access my web application using URL http://hostname:7443/ (no https here) . It returns some garbage value.

I am not able to comprehend why it is returng garbage response. Why even it is returning any response for http?

Probably because the server is only checking for the port, not the actual protocol. It sees a request on port 7443 and sends the encrypted data back. The browser doesn't expect the data to be encrypted though, and that's why you get "garbage" - which is actually the data in its encrypted form.

[Atul Singhal]

Thanks Rob.

You are probably right in your analysis.

Is it possible to redirect this http request to https again for the convenient of the user?

My point is, if by mistake he/she uses http instead of https for the port 7443 , then request should be redirected to https protocol. Possible?

[Rob Spoor]

I haven't done anything like that on Tomcat (only on IIS) so I couldn't tell you. It probably is possible, I just don't know how to.

[Atul Singhal]

Can anyone please suggest here about stopping http request on https port?

[Tim Holloway]

Atul Singhal wrote:Can anyone please suggest here about stopping http request on https port?

It doesn't work that way.

A server machine may have half-a-dozen or more ports open, each speaking its own protocol. I might have a DNS server, 2 database servers (PostgreSQL and MySQL), a Tomcat server, and even an NTP timeserver just for starters.

I can "talk" to any of those ports with any software that is willing to make the attempt. In fact, the "telnet" application is often used to test the text-based server ports such as IMAP and HTTP, and one way to check on potential firewall issues talking to a database server is to attempt telnet connection to its data port, even though the port only carries binary traffic.

There simply is no way to block invalid traffic to a server port - at least short of passing it through another server that understands that particular port's protocol structure and determines the syntactic validity of the request. And most server ports won't simply swallow incoming traffic - no matter how malformed - without attempting to make a reply. But since each protocol is different, there's no universal response that can be issued. It's not even safe to assume that a binary port can respond with a text error message.

"http", when issued as part of a browser URL request is not part of the port request, as such. It's a directive to the client (the browser) to employ the unencrypted HTTP protocol, just as "https" is a directive to the client to use the encrypted HTTP protocol. It doesn't go down directly to the server and direct the server. Although the client URL may be shipped down as part of the request, it's part of the request, not a low-level controlling item.

So, in short, if you send a bad request to any tcp/ip port (including udp ports, icmp ports, and so forth), you can expect a bad reponse.

The only real cure is to make it unnatural to send a bad request. For http/https, one of the easiest ways to do that is to listen on ports 80 and 8443, respectively, since those are their protocols' implicit port numbers, and what users don't code, they are less likely to screw up.

[Atul Singhal]

Thanks Tim for the insight!!!

So, basically you are saying, it is fine to expect a bad response for a bad request and there is no security hole.

Actually, I tested the same thing in weblogic server as well where I used http instead of https for the secure connection. But, I noticed weblogic server doesn't respond at all not even with garbage value. So, I was tempted to understand why tomcat is responding for the bad request but not weblogic. I was also keen to understand how weblogic server handles such requests so that no response is sent for the bad request.

[Jayesh A Lalwani]

The way I have seen this done before is usually we have Apache in front of Tomcat that does URL rewriting and acts as a load balancer. You can put a rule in Apache that redirects all http traffic to https. You can do something like this