Weird behavior of https clients on 16.04 and 18.04, ssl related
I have two ubuntu boxes, let's say box A (16.04) and box B(18.04). They access internet in a significantly different way, but typically I use VPS C(16.04) as a proxy (tinyproxy)
There is a site, allowing for optional ssl protection. I can open it without SSL (http:// prefix) from both machines in any way imaginable. However, when I use SSL (https:// prefix) I can open it from box B both with and without proxy C involved, but cannot open from box A with or without proxy. There is NO error message, the connection simply times out on "waiting for...". Similar behaviour was found for Chromium and wget.
The problem occurs with at least one site, but most are unaffected.
WTF?
How can I diagnose the problem further?
edit: box A has IPv4 address and IS behind a firewall that, for example, blocks incoming connections on SSH default port. Box B doesn't have direct IP address and is behind two levels of NAT. However, both A and B connect to C (and talk to C) via an encripted openVPN tunnel which is not blocked or inspected.
The problem clearly is in box A, it cannot be anywhere else. But I never configured any firewals on it, so if there is anything blocking connection, I didn't install it or at the very least I do not remember installing it.
ssl
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
I have two ubuntu boxes, let's say box A (16.04) and box B(18.04). They access internet in a significantly different way, but typically I use VPS C(16.04) as a proxy (tinyproxy)
There is a site, allowing for optional ssl protection. I can open it without SSL (http:// prefix) from both machines in any way imaginable. However, when I use SSL (https:// prefix) I can open it from box B both with and without proxy C involved, but cannot open from box A with or without proxy. There is NO error message, the connection simply times out on "waiting for...". Similar behaviour was found for Chromium and wget.
The problem occurs with at least one site, but most are unaffected.
WTF?
How can I diagnose the problem further?
edit: box A has IPv4 address and IS behind a firewall that, for example, blocks incoming connections on SSH default port. Box B doesn't have direct IP address and is behind two levels of NAT. However, both A and B connect to C (and talk to C) via an encripted openVPN tunnel which is not blocked or inspected.
The problem clearly is in box A, it cannot be anywhere else. But I never configured any firewals on it, so if there is anything blocking connection, I didn't install it or at the very least I do not remember installing it.
ssl
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41
add a comment |
I have two ubuntu boxes, let's say box A (16.04) and box B(18.04). They access internet in a significantly different way, but typically I use VPS C(16.04) as a proxy (tinyproxy)
There is a site, allowing for optional ssl protection. I can open it without SSL (http:// prefix) from both machines in any way imaginable. However, when I use SSL (https:// prefix) I can open it from box B both with and without proxy C involved, but cannot open from box A with or without proxy. There is NO error message, the connection simply times out on "waiting for...". Similar behaviour was found for Chromium and wget.
The problem occurs with at least one site, but most are unaffected.
WTF?
How can I diagnose the problem further?
edit: box A has IPv4 address and IS behind a firewall that, for example, blocks incoming connections on SSH default port. Box B doesn't have direct IP address and is behind two levels of NAT. However, both A and B connect to C (and talk to C) via an encripted openVPN tunnel which is not blocked or inspected.
The problem clearly is in box A, it cannot be anywhere else. But I never configured any firewals on it, so if there is anything blocking connection, I didn't install it or at the very least I do not remember installing it.
ssl
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
I have two ubuntu boxes, let's say box A (16.04) and box B(18.04). They access internet in a significantly different way, but typically I use VPS C(16.04) as a proxy (tinyproxy)
There is a site, allowing for optional ssl protection. I can open it without SSL (http:// prefix) from both machines in any way imaginable. However, when I use SSL (https:// prefix) I can open it from box B both with and without proxy C involved, but cannot open from box A with or without proxy. There is NO error message, the connection simply times out on "waiting for...". Similar behaviour was found for Chromium and wget.
The problem occurs with at least one site, but most are unaffected.
WTF?
How can I diagnose the problem further?
edit: box A has IPv4 address and IS behind a firewall that, for example, blocks incoming connections on SSH default port. Box B doesn't have direct IP address and is behind two levels of NAT. However, both A and B connect to C (and talk to C) via an encripted openVPN tunnel which is not blocked or inspected.
The problem clearly is in box A, it cannot be anywhere else. But I never configured any firewals on it, so if there is anything blocking connection, I didn't install it or at the very least I do not remember installing it.
ssl
ssl
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
edited Jan 16 at 16:31
permeakra
asked Jan 16 at 14:13
permeakrapermeakra
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Jan 16 at 14:13
permeakrapermeakra
1012
asked Jan 16 at 14:13
permeakrapermeakra
1012
1012
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
permeakra is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41
add a comment |
1
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41
1
1
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
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',
autoActivateHeartbeat: false,
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
});
}
});
permeakra is a new contributor. Be nice, and check out our Code of Conduct.
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%2faskubuntu.com%2fquestions%2f1110284%2fweird-behavior-of-https-clients-on-16-04-and-18-04-ssl-related%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
permeakra is a new contributor. Be nice, and check out our Code of Conduct.
permeakra is a new contributor. Be nice, and check out our Code of Conduct.
permeakra is a new contributor. Be nice, and check out our Code of Conduct.
permeakra is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Ask Ubuntu!
- 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%2faskubuntu.com%2fquestions%2f1110284%2fweird-behavior-of-https-clients-on-16-04-and-18-04-ssl-related%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
1
My guess is that there is some DPI product (firewall, IDS, IPS..) which restricts what sites and with protocols A can access. It does not matter much for this if A is accessing the https site through a proxy C or directly: the blocking is done before it reaches either the final server (direct access) or the proxy C. The connection to the proxy can be inspected too since it is not encrypted.
– Steffen Ullrich
Jan 16 at 15:00
@SteffenUllrich see update.
– permeakra
Jan 16 at 16:31
If the OpenVPN tunnel actually starts at box A and ends at box C and if the traffic is actually going through this VPN (have you verified this?) then it cannot be something in the middle. I recommend to do a packet capture and compare the traffic from A and B.
– Steffen Ullrich
Jan 16 at 18:41