Ssl – set the SSLInsecureRenegotiation Directive with SetEnvIf

(Back to the days when I used Subversion) I had similar problem with proxying to Apache SVN from Nginx SSL frontend. Suppose Nginx SSL frontend is https ://host and we'd like to proxy connections to the internal Apache SVN server http ://svn

The problem occurs when you try to copy a resource is with Destination header:

COPY /path HTTP/1.1
Host: host
Destination: https://host/another_path

As you can see Destination header still contains https schema. The fix is pretty evident --

location / {
    # to avoid 502 Bad Gateway:
    # http://vanderwijk.info/Members/ivo/articles/ComplexSVNSetupFix
    set $destination $http_destination;

    if ($destination ~* ^https(.+)$) {
         set $destination http$1;
    }

    proxy_set_header Destination $destination;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;

    proxy_pass http://svn;
}

SSL connections have extra options for CustomLog but they're not going to break down the step-by-step connection status. You'll probably want to try LogLevel debug, but that will get you plenty of extra junk to wade through.

Honestly, a better idea for this class would be to demonstrate using the openssl s_server command, since it can be configured to show the step-by-step progress of the SSL state machine, you'll be able to see exactly at what step the client dropped the connection.

Something like

openssl s_server -key [somekey.pem] -cert [somecert.pem] -accept 443 -state -www 

When someone connects it'll print off the steps of the connection:

SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data

the -www option makes it print some information when someone actually connects to it with a webbrowser. If the user navigates away without accepting the fake cert, then I'm guessing the connection will be broken somewhere in the middle there.

You can use the openssl s_client command in a similar fashion, though I'm not certain how flexible it is about accepting or not accepting invalid certificates.