How to forward a SSL session?











up vote
1
down vote

favorite












Suppose I have two local machines A and B, and there is also a remote server C.
Originally if I want to visit some resources on C, I can use: https://domain_of_C/some_resources



Now the requirement is that I need to first talk to machine B by using: https://IP_address_of_B/some_resources, and then machine B should be capable of forwarding the request to the remote server C, and getting the correct response back to machine A.



I am having the question that how can I make machine B so that it blindly passes through the data, including the SSL session itself? I don't know if this is even possible.










share|improve this question




























    up vote
    1
    down vote

    favorite












    Suppose I have two local machines A and B, and there is also a remote server C.
    Originally if I want to visit some resources on C, I can use: https://domain_of_C/some_resources



    Now the requirement is that I need to first talk to machine B by using: https://IP_address_of_B/some_resources, and then machine B should be capable of forwarding the request to the remote server C, and getting the correct response back to machine A.



    I am having the question that how can I make machine B so that it blindly passes through the data, including the SSL session itself? I don't know if this is even possible.










    share|improve this question


























      up vote
      1
      down vote

      favorite









      up vote
      1
      down vote

      favorite











      Suppose I have two local machines A and B, and there is also a remote server C.
      Originally if I want to visit some resources on C, I can use: https://domain_of_C/some_resources



      Now the requirement is that I need to first talk to machine B by using: https://IP_address_of_B/some_resources, and then machine B should be capable of forwarding the request to the remote server C, and getting the correct response back to machine A.



      I am having the question that how can I make machine B so that it blindly passes through the data, including the SSL session itself? I don't know if this is even possible.










      share|improve this question















      Suppose I have two local machines A and B, and there is also a remote server C.
      Originally if I want to visit some resources on C, I can use: https://domain_of_C/some_resources



      Now the requirement is that I need to first talk to machine B by using: https://IP_address_of_B/some_resources, and then machine B should be capable of forwarding the request to the remote server C, and getting the correct response back to machine A.



      I am having the question that how can I make machine B so that it blindly passes through the data, including the SSL session itself? I don't know if this is even possible.







      networking ssl https






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 21 at 7:47









      Mureinik

      2,23151525




      2,23151525










      asked Nov 20 at 19:33









      peakpeaktan

      61




      61






















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          1
          down vote













          This is a reverse proxy situation and is supported by major webservers such as nginx, apache, and IIS.



          In each of these, you can define a path such as "/application" - and instead of looking in a corresponding local directory and delivering a file, or calling a script interpreter, it will talk to another webserver instead. It will then forward back the reply it got.



          If you specify an HTTPS site, it will talk HTTPS to the "backend" webserver, as though it was a web browser. With most webservers you can control which headers from the "frontend" request are copied to the backend request, have the webserver modify or filter them, or add additional ones.



          A won't even know C exists and this is what you want. Ideally C should only be accessible to B, and if you are 100% confident of that, you can dispense with HTTPS between B and C for a bit of performance if it matters to your hardware and load (when you get to thousands of requests per second it might matter). If your "backend" webserver is really on the same machine or VM and is listening on 127.0.0.1, HTTPS might be overkill, for example.



          Nginx is well known for being fast and often used for caching. The combination of Nginx with paths reverse proxied to another webserver such as Apache is common and often used.



          If you want to get elaborate, and your web applications are designed to support it, you can specify multiple backend webservers for a single path to do load balancing or failover.



          Configuring reverse proxy depends on the specific webserver, but ought to be easily searchable by "nginx reverse proxy", etc.






          share|improve this answer





















          • Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
            – dave_thompson_085
            Nov 21 at 10:20













          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "3"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377081%2fhow-to-forward-a-ssl-session%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          1
          down vote













          This is a reverse proxy situation and is supported by major webservers such as nginx, apache, and IIS.



          In each of these, you can define a path such as "/application" - and instead of looking in a corresponding local directory and delivering a file, or calling a script interpreter, it will talk to another webserver instead. It will then forward back the reply it got.



          If you specify an HTTPS site, it will talk HTTPS to the "backend" webserver, as though it was a web browser. With most webservers you can control which headers from the "frontend" request are copied to the backend request, have the webserver modify or filter them, or add additional ones.



          A won't even know C exists and this is what you want. Ideally C should only be accessible to B, and if you are 100% confident of that, you can dispense with HTTPS between B and C for a bit of performance if it matters to your hardware and load (when you get to thousands of requests per second it might matter). If your "backend" webserver is really on the same machine or VM and is listening on 127.0.0.1, HTTPS might be overkill, for example.



          Nginx is well known for being fast and often used for caching. The combination of Nginx with paths reverse proxied to another webserver such as Apache is common and often used.



          If you want to get elaborate, and your web applications are designed to support it, you can specify multiple backend webservers for a single path to do load balancing or failover.



          Configuring reverse proxy depends on the specific webserver, but ought to be easily searchable by "nginx reverse proxy", etc.






          share|improve this answer





















          • Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
            – dave_thompson_085
            Nov 21 at 10:20

















          up vote
          1
          down vote













          This is a reverse proxy situation and is supported by major webservers such as nginx, apache, and IIS.



          In each of these, you can define a path such as "/application" - and instead of looking in a corresponding local directory and delivering a file, or calling a script interpreter, it will talk to another webserver instead. It will then forward back the reply it got.



          If you specify an HTTPS site, it will talk HTTPS to the "backend" webserver, as though it was a web browser. With most webservers you can control which headers from the "frontend" request are copied to the backend request, have the webserver modify or filter them, or add additional ones.



          A won't even know C exists and this is what you want. Ideally C should only be accessible to B, and if you are 100% confident of that, you can dispense with HTTPS between B and C for a bit of performance if it matters to your hardware and load (when you get to thousands of requests per second it might matter). If your "backend" webserver is really on the same machine or VM and is listening on 127.0.0.1, HTTPS might be overkill, for example.



          Nginx is well known for being fast and often used for caching. The combination of Nginx with paths reverse proxied to another webserver such as Apache is common and often used.



          If you want to get elaborate, and your web applications are designed to support it, you can specify multiple backend webservers for a single path to do load balancing or failover.



          Configuring reverse proxy depends on the specific webserver, but ought to be easily searchable by "nginx reverse proxy", etc.






          share|improve this answer





















          • Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
            – dave_thompson_085
            Nov 21 at 10:20















          up vote
          1
          down vote










          up vote
          1
          down vote









          This is a reverse proxy situation and is supported by major webservers such as nginx, apache, and IIS.



          In each of these, you can define a path such as "/application" - and instead of looking in a corresponding local directory and delivering a file, or calling a script interpreter, it will talk to another webserver instead. It will then forward back the reply it got.



          If you specify an HTTPS site, it will talk HTTPS to the "backend" webserver, as though it was a web browser. With most webservers you can control which headers from the "frontend" request are copied to the backend request, have the webserver modify or filter them, or add additional ones.



          A won't even know C exists and this is what you want. Ideally C should only be accessible to B, and if you are 100% confident of that, you can dispense with HTTPS between B and C for a bit of performance if it matters to your hardware and load (when you get to thousands of requests per second it might matter). If your "backend" webserver is really on the same machine or VM and is listening on 127.0.0.1, HTTPS might be overkill, for example.



          Nginx is well known for being fast and often used for caching. The combination of Nginx with paths reverse proxied to another webserver such as Apache is common and often used.



          If you want to get elaborate, and your web applications are designed to support it, you can specify multiple backend webservers for a single path to do load balancing or failover.



          Configuring reverse proxy depends on the specific webserver, but ought to be easily searchable by "nginx reverse proxy", etc.






          share|improve this answer












          This is a reverse proxy situation and is supported by major webservers such as nginx, apache, and IIS.



          In each of these, you can define a path such as "/application" - and instead of looking in a corresponding local directory and delivering a file, or calling a script interpreter, it will talk to another webserver instead. It will then forward back the reply it got.



          If you specify an HTTPS site, it will talk HTTPS to the "backend" webserver, as though it was a web browser. With most webservers you can control which headers from the "frontend" request are copied to the backend request, have the webserver modify or filter them, or add additional ones.



          A won't even know C exists and this is what you want. Ideally C should only be accessible to B, and if you are 100% confident of that, you can dispense with HTTPS between B and C for a bit of performance if it matters to your hardware and load (when you get to thousands of requests per second it might matter). If your "backend" webserver is really on the same machine or VM and is listening on 127.0.0.1, HTTPS might be overkill, for example.



          Nginx is well known for being fast and often used for caching. The combination of Nginx with paths reverse proxied to another webserver such as Apache is common and often used.



          If you want to get elaborate, and your web applications are designed to support it, you can specify multiple backend webservers for a single path to do load balancing or failover.



          Configuring reverse proxy depends on the specific webserver, but ought to be easily searchable by "nginx reverse proxy", etc.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 20 at 19:51









          LawrenceC

          58.4k10100178




          58.4k10100178












          • Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
            – dave_thompson_085
            Nov 21 at 10:20




















          • Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
            – dave_thompson_085
            Nov 21 at 10:20


















          Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
          – dave_thompson_085
          Nov 21 at 10:20






          Also haproxy. Note this passes through HTTP(S) requests and responses, possibly with modification, but not 'SSL session' as requested: A sees cert of B not C (though you might make them the same), and if you use client certs B sees A's cert and proof but C doesn't; at best it sees cert data added to the request header by B, and must trust B. OTOH nginx and haproxy also support TCP-level forwarding ('stream' and 'mode tcp', see many Qs on various Stacks), as do the various versions of netcat and socat. Also ssh tunnel and stunnel, but those unnecessarily re-encrypt.
          – dave_thompson_085
          Nov 21 at 10:20




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Super User!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1377081%2fhow-to-forward-a-ssl-session%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          AnyDesk - Fatal Program Failure

          How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

          QoS: MAC-Priority for clients behind a repeater