Apache Reverse Proxy w/ SSL Downgrade



  • I'm trying to do some security "improvements" on an ancient but critical LOB web facing server (the web service is tightly bound to an application that is tightly bound to the specific OS to which the application is installed). Part of this effort includes putting the application behind a reverse proxy so it can support more modern SSL ciphers and protocols. There's no person at the organization left who is knowledgeable about the application, so they are incredibly adverse to making any modifications to the application source code.

    We have an Apache proxy installed in front of the server, but when the proxy attempts to connect to the LOB server, the server rejects the connection because it doesn't support any of the SSL protocols that our Apache server supports.

    Does anyone have any experience performing an SSL downgrade within an Apache proxy server? My Google-Fu seems to be letting me down on this one.


  • Java Dev

    I think you're looking for an SSL offloader configuration.



  • Meaning that the connection to the LOB is HTTP?

    If so, that's what we have configured, but the LOB app is written poorly and so it randomly demands an HTTPS connection depending on the page. The LOB server can't support anything better than SSLv2, and I can't figure out how to use an SSLv2 tunnel to the LOB while accepting only TLSv1.0+ connections from WWW.



  • Can you PM me the URL of the server, perhaps? I might be able to help you more then. I've got a lot of experience with this kind of stuff.


  • Java Dev

    I have heard of SSL offloader configurations which merely transitioned to a cheaper form of SSL rather than to plain, but getting a modern apache to speak SSLv2 may indeed be tricky.



  • Apache2 does speak SSLv2 (by default even :( :( ); I just don't know how to get it to speak TLSv1+ on the front side but speak SSLv2 on the back side when I've disabled all incoming connections below SSLv1.

    The LOB server is, theoretically, going away within a year, AND the sprint team is even on track, from my POV, to hit the projected deploy date so far. I just need enough security to keep the service up and running while containing the damage to the DMZ for them every time this server gets hacked.

    Note: I'm just the HPC on this work; my access is limited and I only have so much political capital before I'm no longer effective in correcting the glaring problems they have on the infrastructure side. I'm spending pretty much all of my capital on this app, but there's some battles around it that I'll never win so it's not worth trying.



  • I don't know if this is an option, but nginx reverse proxies are FAR easier to configure than Apache reverse proxies.



  • It is an option; I just have no experience with nginx .... if you could point to a verified source regarding an SSL downgrade instead of an SSL offloader, I'd appreciate.



  • What's SSL downgrade? I googled it and it seems to be an attack of some kind?


  • Java Dev

    He wants something to which customers can connect using TLSv1.2 with modern security requirements, but which will then forward to his backend server using SSLv2. Talking plain to the backend like an SSL offloader would typically do won't work because the backend server is checking it's on SSL in places.



  • Basically? Yeah.

    The server I'm working with can't support anything better than SSLv2. Most browsers will now reject or scream about SSLv3 or lower connections. This really small part of securing this really old server is making SSL work properly and reliably.

    Edit: the difference is the "attack" usually involves an MITM process to force the client connection to use a lower quality or naked connection to steal the communication contents (e.g. username, password, bank account id, etc.), whereas we need it because the app is FUBAR and has nobody who knows how it works, so I need to support low quality SSL instead of just doing offloading like I would do in a non-stupid scenario.



  • Offloading would work, if this app wasn't written in the wild wild west days of websites. It's been a long time since I've seen Auth over GET ... just sayin*.

    *The app vintage shows that this mistake wouldn't have been obvious. It's a 2000 era application.



  • I think it would Just Work. You'd have one type of SSL between the client and nginx, and a different type of SSL between nginx and the final server, and I don't think there's any special configuration to do so.


  • Garbage Person

    You could reverse proxy to plaintext, thence to another reverse proxy into SSLv2. Just sayin'.



  • Well, that seems needlessly baroque. Apache should be able to handle the transition.



  • That's what I thought about Apache ... I'm betting that disallowing SSLv2 in Apache does it for both sides of the pipe. If i knew for certain that inserting nginx would fix it, I could recommend, but without an auhoritative source I've got 0% chance of changing course mid-stream here.

    We could probably "double proxy" it (e.g. http downgrade to localhost on a different port and then re-upgrade at the 2nd proxy to SSLv2), but that just feels too much like a wooden table approach.


  • Java Dev

    Possibly. In that case you'll want to check the documentation on the ciphers directive. You may be able to scope them so that different versions are used for incoming and outgoing.



  • Good idea; there are SSLProxy* directives for mod_ssl. I'll look into them.



  • We've successfully set up the proxy the relevant portion of the proxy.conf file is below

    <VirtualHost>
        <IfModlue>
            SSLProxyEngine on
            SSLProxyProtocol +SSLv3 +TLSv1
            SSLProxyCipherSuite "SSLv3 TLSv1 LOW MEDIUM HIGH"
            ProxyPass / balancer://example
        </IfModlue>
    </VirtualHost>
    <Proxy balancer://example>
        BalancerMember https://example.com
    </Proxy>
    

    EDIT: also @rc4 was a great help over PM regarding this issue. Their help was instrumental in us correcting the problem.

    EDIT2:

    We had 2 issues, first was the lack of the SSLProxy* directives; second was that we had originally planned to do SSL stripping at the proxy and we discovered that a dll on the host was configured to require an SSL connection to function properly. When we originally wrote the balancer, we directed it to http instead of https (and the host had a hard-coded https redirect that we were not allowed to change), which caused a redirect loop resulting in a 500 error.


Log in to reply