I guess I could expound upon that a little more. Rocket does not allow insecure connections on secure sockets. So if a secure connection fails for whatever reason it will fail (here https://github.com/explorigin/Rocket/blob/master/rocket/listener.py#L106 ) but what happens is that the returned socket is a normal socket not an SSLSocket. The actual detection is a combination of things:
1) The Connection object detects if the connection is secure or not and also records if it should be secure (here: https://github.com/explorigin/Rocket/blob/master/rocket/connection.py#L45 ) 2) The Worker class compares these values such that if a socket is supposed to be secure but is not, it will close the connection and not process the request (here: https://github.com/explorigin/Rocket/blob/master/rocket/worker.py#L155 ). The code is not awesomely concise, but the net effect is that no insecure connections get processed as secure ones. I left the try/except block in there so that it wouldn't fail there so my listener threads weren't also having to handle responses. There seemed little reason to log the error (to me) since if things were setup correctly, it wouldn't error in interesting scenarios. However it's useful when developing (as Michele figured out) to add a log line there. I'm open to there being a log line there but I think it will overload the logfiles with useless messages because there are scanners all over the internet that try to connect to secure sockets insecurely all the time. I'm open to ideas. Share them with me. =) -tim On Sep 26, 11:29 am, Jonathan Lundell <jlund...@pobox.com> wrote: > On Sep 26, 2011, at 9:07 AM, Michele Comitini wrote: > > > > > > > > > > > Ross, Jonathan, > > > I was the guilty one to put the log line, since I had to debug the new > > ssl code which can optionally check for a client submitted x509 cert. > > I left it there because IMHO the try/except/pass pattern can be > > dangerous and hide serious low level errors. > > The specific matter seems to point to an error happening only on > > certain Python and/or OpenSSL version combinations. *It seems > > harmless*. > > What I can suggest is trying to upgrade to latest OpenSSL major > > version and Python minor and see the problem persists. It does not > > depend on Web2Py for as much I can see. > > > In any case even if it is clear that the error was there before but > > hiddend, it must be addressed because it is related to security and > > integrity of the trasmitted data. > > I expect you're right here; at the very least the code should have been more > specific about the errors it was ignoring. And the "detected by Worker" > comment is at least suspect. > > > > > > > > > > > mic > > > 2011/9/26 Jonathan Lundell <jlund...@pobox.com>: > >> On Sep 26, 2011, at 8:27 AM, Ross Peoples wrote: > > >>> It was the admin application, which should be using HTTPS when you access > >>> it over HTTPS right? I just tried with a test app and the same thing > >>> happens. > > >>> I commented out like 518 in rocket.py and that silences the errors, but > >>> is that a good thing? > > >> I don't know. I looked at the recent changes in rocket.py, and the > >> addition of that log line is the only change that I can see that looks > >> relevant if you're not using a client certificate. Notice the (existing) > >> comment: > > >> except SSLError: > >> # Generally this happens when an HTTP request is received on a > >> # secure socket. We don't do anything because it will be > >> detected > >> # by Worker and dealt with appropriately. > >> self.err_log.error('SSL Error: %s' % traceback.format_exc()) > >> <<<<<-- this was added > >> pass > > >> It may well be that the lack of a log here was hiding *other* errors that > >> we ought to know about. > > >> There is actually one other block of new code: > > >> if conn.ssl: > >> try: > >> peercert = conn.socket.getpeercert(binary_form=True) > >> environ['SSL_CLIENT_RAW_CERT'] = \ > >> peercert and ssl.DER_cert_to_PEM_cert(peercert) > >> except Exception,e: > >> print e > > >> The cert is being captured for use by the X509 code. Looks harmless, and > >> you're not getting that exception. > > >>> There might be another problem here. I just checked the traffic going to > >>> my test app and all requested files (including the static ones) are > >>> requested over HTTPS, however, Google Chrome has disabled my JavaScript > >>> because "This page has insecure content". All the static files are loaded > >>> locally (I'm not using a CDN or anything). So are the files getting > >>> returned to the browser over HTTP instead of HTTPS or something and > >>> that's why the rocket error was happening?
