Hi Angelo, On Thu, Aug 16, 2018 at 03:48:22AM +0200, Angelo Höngens wrote: > Hey guys, > > I'm building a solution where I am ssl-offloading some old plain http > applications. > > The http ports are listening on 8001, 8002, 8003, etc. I'm using haproxy > 1.8.12 to listen on ports 18001, 18002, 18003, etc. using ssl. Everything > works fine, as expected. > > I am trying to make stuff a bit more fool-proof for stupid users, and > testing stuff like talking http to https ports, etc. These things are not > supposed to happen, but users sometimes do stupid stuff like that. > > When I talk http to a https port, I would expect something like an error > message 'ERROR 400: You are talking http to a https port', or something > like that. This makes it clear to users what they are doing wrong. (Apache > does this.) > > However, I get no reply whatsoever. Not even a status code, haproxy just > closes the connection, and curl just says: "* Empty reply from server". > Haproxy logs a nice "SSL handshake failure" error in it's logs, as expected. > > I don't know if haproxy was designed to just keep quiet, but I would love > to get a nice error message back. Is this something configurable?
We've thought about it already. The thing is, openssl directly reads from the socket so when it fails to parse the data we have no idea what was found there. We could decide to waste CPU cycles and memory by performing a call to recv(MSG_PEEK) before openssl reads the contents so that in case of handshake failure we can check if it looks like HTTP, but the reality is that it would impact performance for power users with little benefit. However along the connection layering rewrite, we have plans to split the SSL layer and ensure that openssl will not directly manipulate the FD. Thus it will become much easier over the mid term to do something like this. That's all I can propose for now. Regards, Willy
