On Tuesday, September 24, 2013, Jason Haar  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>On 25/09/13 00:43, Gary Chodos wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div>We are trying to decide between SNIProxy and stunnel for the
        following task:</div>
      <div><br>
      </div>
      <div>- Client browser hits <a href="https://foo.bar.org" target="_blank">https://foo.bar.org</a>, which
        resolves to an IP that corresponds to the stunnel machine
        listening on 443.</div>
      <br>
      <div>- stunnel "forwards" (sorry if this is not the correct
        technical term) the connection to a different machine, specified
        by a different IP address, which is also configured to believe
        it is <a href="http://foo.bar.org" target="_blank">foo.bar.org</a>
        and actually has a web server listening on 443 and houses the
        SSL key/cert.</div>
      <div><br>
      </div>
    </blockquote>
    What an odd setup. You want to make an HTTPS connection to an IP
    address, but want that to make an HTTPS connection to another IP
    address, but don't want it to house the SSL cert.</div></blockquote><div><br></div><div>Correct.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
    That isn't possible - an "SSL terminator" requires the cert -
    otherwise it isn't terminating the SSL connection. Why don't you
    just use a standard TCP forwarder instead - won't that do what you
    want? Don't forget: SSL occurs *within* a TCP session - so a
    standard TCP forwarder can "reroute" the SSL transaction without
    needing to know what it is forwarding (ie no need for certs)<br>
    <br>
    You could use xinetd or netcat - tonnes of options</div></blockquote><div><br></div><div>Thanks to cluebats from you and the kind folks over on the nginx list, we went with haproxy in tcpmode.</div><div><br></div><div>
Thanks,</div><div>Gary�</div><div>�</div>