Re: [racket-dev] possible bug in openssl/mzssl
This repair seems to have broken uses of `net/url' over SSL. For example, this: (get-pure-port (string->url "https://api.github.com/";)) produces: # ; read-bytes: SSL read failed #f ; === context === ; /home/samth/sw/plt/collects/openssl/mzssl.rkt:235:2: error/network ; /home/samth/sw/plt/collects/mzlib/port.rkt:133:4: do-read-it ; /home/samth/sw/plt/collects/mzlib/private/port.rkt:102:4: loop ; /home/samth/sw/plt/collects/net/url.rkt:367:3 On Thu, Mar 1, 2012 at 1:05 PM, Matthew Flatt wrote: > > I've pushed a repair. The problem was that the `pump-output' call was > too early; it needs to happen after SSL_read(), in case the SSL_read() > triggers new output for the socket level. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
At Thu, 1 Mar 2012 09:31:40 +0400, Sergey Pinaev wrote: > On Wed, 29 Feb 2012 09:20:54 -0700 > Matthew Flatt wrote: > > > Neil and Timur: Thanks for detailed information about the problem. > > > > So far, I haven't managed to replicate the problem on my machine. Do > > you have any hints on how to configure Apache to trigger the problem > > or a server that I might try? > > you must access document in location, where SSLVerifyClient required: > > > SSLRequireSSL > SSLVerifyClient require > SSLVerifyDepth 10 > > > and do "GET /dir/some.file HTTP/1.0" to cause apache do connection > re-negotiation. Ah, now I get it. If the server requires a certificate for all connections, then there's no problem. It's only when certificate verification is triggered after some communication that the problem happens. I've pushed a repair. The problem was that the `pump-output' call was too early; it needs to happen after SSL_read(), in case the SSL_read() triggers new output for the socket level. I also added support for renegotiation to the library, which makes it easier to write tests for problems exposed by renegotiation. Thanks! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
On Wed, 29 Feb 2012 09:20:54 -0700 Matthew Flatt wrote: > Neil and Timur: Thanks for detailed information about the problem. > > So far, I haven't managed to replicate the problem on my machine. Do > you have any hints on how to configure Apache to trigger the problem > or a server that I might try? you must access document in location, where SSLVerifyClient required: SSLRequireSSL SSLVerifyClient require SSLVerifyDepth 10 and do "GET /dir/some.file HTTP/1.0" to cause apache do connection re-negotiation. -- Sergey Pinaev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
Matthew Flatt wrote at 02/29/2012 11:20 AM: So far, I haven't managed to replicate the problem on my machine. Do you have any hints on how to configure Apache to trigger the problem or a server that I might try? I'm afraid I don't have that test setup or notes anymore. I do recall it was with PLT 4.2.5 (CGC collector) on Debian Stable (Lenny) 32-bit x86 machine with the Apache that Debian packaged, in a pretty stock configuration. (This was likely also tested on other systems, but I can't say for certain.) As noted in the email thread back then, every other HTTPS client tool I tried with the same files and server worked fine. It's possible that I made a bug in the Scheme code, but everything I did was pretty straightforward, and I could not see a bug. Unfortunately, I couldn't share a complete test case for a PLT bug report at the time, or perhaps we could have figured it out then. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
Neil and Timur: Thanks for detailed information about the problem. So far, I haven't managed to replicate the problem on my machine. Do you have any hints on how to configure Apache to trigger the problem or a server that I might try? I've tried connecting to an Apache servers running on 64-bit Mac OS X and 32-bit Linux. I tried connecting to "localhost", and I tried bouncing the connection through `ssh -L ... -R ...' to distant hosts. All of those configurations worked. Meanwhile, I'm pretty sure that I'm setting up client verification correctly, since the connection fails if I mangle the certificate configuration on the client side. I wonder whether there's some other feature in Apache I could turn on that would trigger problems. At Tue, 28 Feb 2012 18:41:23 -0500, Neil Van Dyke wrote: > Timur Sufiev wrote at 02/27/2012 08:58 AM: > > [...] Raw ports were wrapped with SSL successfully, but then program > > has hung up between 2 last actions: sending the request to server and > > reading its reply. Further investigation showed that in the course of > > SSL processing the server had requested session renegotiation from the > > client and would provide it with requested data if the client sent > > negotiation info to server. [...] > > This sounds like a problem that I had over a year ago with having Racket > (PLT Scheme) send HTTPS client certificates: > http://lists.racket-lang.org/users/archive/2010-September/041519.html > > I did not solve that exact problem. A consulting client had an urgent > need, so I worked around the problem by making a Racket module that > provided an abstraction over external "curl" processes, and used that > module instead. (Which also probably increased app performance, when > that client moved to Web SCGI with Racket and added some new behavior, > since large HTTPS and file I/O that happened in the background of Web > requests could bypass the Racket process and could also be scheduled by > the host OS on other processors.) That particular Racket "curl" module > is not currently open source, but you might find a similar Racket > library, or implement your own simple library pretty easily. > > Also, a tip on one way to decrypt the SSL traffic: > http://www.neilvandyke.org/weblog/2010/09/#2010-09-12 > > Neil V. > > -- > http://www.neilvandyke.org/ > > _ > Racket Developers list: > http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] possible bug in openssl/mzssl
Timur Sufiev wrote at 02/27/2012 08:58 AM: [...] Raw ports were wrapped with SSL successfully, but then program has hung up between 2 last actions: sending the request to server and reading its reply. Further investigation showed that in the course of SSL processing the server had requested session renegotiation from the client and would provide it with requested data if the client sent negotiation info to server. [...] This sounds like a problem that I had over a year ago with having Racket (PLT Scheme) send HTTPS client certificates: http://lists.racket-lang.org/users/archive/2010-September/041519.html I did not solve that exact problem. A consulting client had an urgent need, so I worked around the problem by making a Racket module that provided an abstraction over external "curl" processes, and used that module instead. (Which also probably increased app performance, when that client moved to Web SCGI with Racket and added some new behavior, since large HTTPS and file I/O that happened in the background of Web requests could bypass the Racket process and could also be scheduled by the host OS on other processors.) That particular Racket "curl" module is not currently open source, but you might find a similar Racket library, or implement your own simple library pretty easily. Also, a tip on one way to decrypt the SSL traffic: http://www.neilvandyke.org/weblog/2010/09/#2010-09-12 Neil V. -- http://www.neilvandyke.org/ _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] possible bug in openssl/mzssl
Consider the following code: (define cert-chain "/opt/dozor/smap/config/httpd/server.crt") (define cert-root "/opt/dozor/smap/config/httpd/server.crt") (define cert-sca "/opt/dozor/smap/config/httpd/server.crt") (define key "/opt/dozor/smap/config/httpd/server.key") (let-values (((in-raw out-raw) (tcp-connect "localhost" 8052))) (let-values (((in out) (let ((ctx (ssl-make-client-context))) (ssl-load-certificate-chain! ctx cert-chain) (ssl-load-verify-root-certificates! ctx cert-root) (ssl-load-suggested-certificate-authorities! ctx cert-sca) (ssl-set-verify! ctx #t) (ssl-load-private-key! ctx key) (ports->ssl-ports in-raw out-raw #:mode 'connect #:context ctx #:close-original? #t #:shutdown-on-close? #f (fprintf out "GET https://localhost:8052/cgi-bin/rc/iface.scm HTTP/1.0\r\n\r\n") (flush-output out) (read-line in))) Raw ports were wrapped with SSL successfully, but then program has hung up between 2 last actions: sending the request to server and reading its reply. Further investigation showed that in the course of SSL processing the server had requested session renegotiation from the client and would provide it with requested data if the client sent negotiation info to server. After looking inside *make-ssl-input-port *(see the code below) (letrec ([do-read (lambda (buffer) (let ([out-blocked? (pump-output mzssl)] [len (or must-read-len (min (bytes-length xfer-buffer) (bytes-length buffer)))]) (let ([n (SSL_read (mzssl-ssl mzssl) xfer-buffer len)]) we found that control flow cannot reach *SSL_read* call it is blocked by *pump-output* call. Unfortunately, we do not fully understand what is going on inside *pump-output*... -- Best regards, Timur _ Racket Developers list: http://lists.racket-lang.org/dev
