DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=41202>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41202 Summary: strange ssl tomcat response Product: Tomcat 5 Version: 5.5.20 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] After installing and configuring tomcat 5.5 to use ssl if i am trying to request the ssl port with non ssl protocol i am getting a result that i can't understand - this looks like a strange stream of bits. Here are the steps to reproduce: -------------------------------------------------------------------------------------- [1] Do a regular (vanilla) installation of tomcat (Linux and Windows i have already tried) . [2] Setup ssl: Uncomment the ssl setup in server.xml create a key with the following: %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA or $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (taken from tomcat's manual) add the keystorePass and keystoreFile to server.xml start the tomcat and test if the ssl works . [3] Try this in browser: http://localhost:8443 (note the http not the https) or telnet localhost 8443 Note that the telnet should be done from a terminal that can show binary output. (rxvt,xterm will NOT do,for me gnome terminal and cmd on windows worked). in the telnet session you will get a connection type something ,hit ENTER and you will get strange bits in the response. If you are doing this in browser it will just try to download those bits (Mozilla) or show it on the screen (IE). I am pretty sure that this is NOT valid behaviour. I have tried all this on : tomcat 5.5.20 java 1.5.0_09 and same tomcat java 1.5.0_06 Both Linux and Windows . ----------------------------------------------------------------------------------------------------- The same behaviuor was reported on WebSpher server ,so this is probably a jvm problem.However it can be very simple fix in tomcat : if the scheme is not ssl (https) - return 400 error (or whatever it shold be). Just to make it clear : It was suggested by one of the users that this is a tomcat trying to do ssl negotiating. However it seems to me that if client is not sending the ssl negotiating first then server should not try to do this.Here is what i have found in rfc (TLS 1.0): "These goals are achieved by the handshake protocol, which can be summarized as follows: The client sends a client hello message to which the server must respond with a server hello message, or else a fatal error will occur and the connection will fail." Here is the link to the users list for the discussion: http://marc.theaimsgroup.com/?l=tomcat-user&m=116609043103294&w=2 Note also that other servers i have worked with (non-java) do not do this: try to telnet to ssl port of gmail and you will not get any response (connection yes,response - no). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
