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.
networking ssl https
edited Nov 21 at 7:47
Mureinik
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
add a comment |
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.
networking ssl https
edited Nov 21 at 7:47
Mureinik
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
add a comment |
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.
networking ssl https
edited Nov 21 at 7:47
Mureinik
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
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
networking ssl https
edited Nov 21 at 7:47
Mureinik
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
edited Nov 21 at 7:47
Mureinik
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
edited Nov 21 at 7:47
Mureinik
2,24151525
edited Nov 21 at 7:47
Mureinik
2,24151525
edited Nov 21 at 7:47
Mureinik
2,24151525
2,24151525
asked Nov 20 at 19:33
peakpeaktan
61
asked Nov 20 at 19:33
peakpeaktan
61
asked Nov 20 at 19:33
peakpeaktan
61
61
add a comment |
add a comment |
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.
answered Nov 20 at 19:51
LawrenceC
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
add a comment |
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.
answered Nov 20 at 19:51
LawrenceC
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
add a comment |
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.
answered Nov 20 at 19:51
LawrenceC
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
add a comment |
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.
answered Nov 20 at 19:51
LawrenceC
58.4k10100178
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.
answered Nov 20 at 19:51
LawrenceC
58.4k10100178
answered Nov 20 at 19:51
LawrenceC
58.4k10100178
answered Nov 20 at 19:51
LawrenceC
58.4k10100178
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
