As an end user, what risk is there in browsing a public website that uses TLSv1?
Is it safe for an end user to browse a website that only supports TLSv1 (or other insecure ciphers or protocols), given the following:
- it's a publicly accessible website with no sensitive or private data
- it doesn't require user login, credentials or any other user data whatsoever.
So for all intents and purposes, assume the website is intended to be an http://
site, but has an SSL cert installed on it that's out of date by modern security standards.
And by safe, I mean they're not open to some type of exploit, other than MITM of course. By exploit here, I mean there's no way a bad SSL cert could be used to install malware on their machine in anyway, correct?
tls known-vulnerabilities
add a comment |
Is it safe for an end user to browse a website that only supports TLSv1 (or other insecure ciphers or protocols), given the following:
- it's a publicly accessible website with no sensitive or private data
- it doesn't require user login, credentials or any other user data whatsoever.
So for all intents and purposes, assume the website is intended to be an http://
site, but has an SSL cert installed on it that's out of date by modern security standards.
And by safe, I mean they're not open to some type of exploit, other than MITM of course. By exploit here, I mean there's no way a bad SSL cert could be used to install malware on their machine in anyway, correct?
tls known-vulnerabilities
1
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28
add a comment |
Is it safe for an end user to browse a website that only supports TLSv1 (or other insecure ciphers or protocols), given the following:
- it's a publicly accessible website with no sensitive or private data
- it doesn't require user login, credentials or any other user data whatsoever.
So for all intents and purposes, assume the website is intended to be an http://
site, but has an SSL cert installed on it that's out of date by modern security standards.
And by safe, I mean they're not open to some type of exploit, other than MITM of course. By exploit here, I mean there's no way a bad SSL cert could be used to install malware on their machine in anyway, correct?
tls known-vulnerabilities
Is it safe for an end user to browse a website that only supports TLSv1 (or other insecure ciphers or protocols), given the following:
- it's a publicly accessible website with no sensitive or private data
- it doesn't require user login, credentials or any other user data whatsoever.
So for all intents and purposes, assume the website is intended to be an http://
site, but has an SSL cert installed on it that's out of date by modern security standards.
And by safe, I mean they're not open to some type of exploit, other than MITM of course. By exploit here, I mean there's no way a bad SSL cert could be used to install malware on their machine in anyway, correct?
tls known-vulnerabilities
tls known-vulnerabilities
edited Jan 14 at 12:30
Brad Parks
asked Jan 14 at 12:04
Brad ParksBrad Parks
25929
25929
1
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28
add a comment |
1
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28
1
1
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28
add a comment |
2 Answers
2
active
oldest
votes
There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.
On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
add a comment |
As an end user, probably nothing. The very stage where you are at the communication sequence of a TLS transaction makes it so you are not really vulnerable to anything other than MITM.
Most of the discovered vulnerabilities discovered on the protocol and it's implementation itself, on the other hand, may impact the server responsible for hosting it. Even then, TLSv1 is not nearly as problematic as the older brother, SSL.
If we ever achieve RCE on the SSL/TLS communication phase, we are in serious problems.
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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%2fsecurity.stackexchange.com%2fquestions%2f201429%2fas-an-end-user-what-risk-is-there-in-browsing-a-public-website-that-uses-tlsv1%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.
On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
add a comment |
There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.
On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
add a comment |
There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.
On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.
There is currently no real risk just based on the TLS protocol version for the end user when visiting a site which provides only TLS 1.0 (TLSv1) with a modern browser, i.e. a current version of Chrome, Firefox, Edge or chromium based browsers like Opera. Fortunately browser vendors today actually care about security and if TLS 1.0 would be too insecure it would be switched off or be restricted to only some white-listed sites or only for use with some ciphers.
On the other hand: if a site is still offering only TLS 1.0 you might ask yourself how their relation to security is in general. While there might be some sites which knowingly support only TLS 1.0 it is more likely that they use some old systems or setups which is not able to support TLS 1.2 yet. Given that the most commonly used server-side SSL stack OpenSSL has support of TLS 1.2 since version 1.0.1 released in 2012 and that even OpenSSL 1.0.1 is out of support since some time, it is not unlikely that the owners of the site don't really care about security and that the rest of their infrastructure is outdated too. And that should worry you, not the use of TLS 1.0 by itself.
answered Jan 14 at 12:53
Steffen UllrichSteffen Ullrich
116k13200265
116k13200265
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
add a comment |
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
11
11
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
OpenSSL 1.0.1 was the version with the infamous heartbleed bug. When the bug was discovered, some people might have opted to downgrade to the last good version (1.0.0) instead of applying the not yet thoroughly tested patch. Makes you wonder, though, how they never bothered to replace that temporary crutch and return to the most recent version.
– Philipp
Jan 14 at 16:56
add a comment |
As an end user, probably nothing. The very stage where you are at the communication sequence of a TLS transaction makes it so you are not really vulnerable to anything other than MITM.
Most of the discovered vulnerabilities discovered on the protocol and it's implementation itself, on the other hand, may impact the server responsible for hosting it. Even then, TLSv1 is not nearly as problematic as the older brother, SSL.
If we ever achieve RCE on the SSL/TLS communication phase, we are in serious problems.
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
add a comment |
As an end user, probably nothing. The very stage where you are at the communication sequence of a TLS transaction makes it so you are not really vulnerable to anything other than MITM.
Most of the discovered vulnerabilities discovered on the protocol and it's implementation itself, on the other hand, may impact the server responsible for hosting it. Even then, TLSv1 is not nearly as problematic as the older brother, SSL.
If we ever achieve RCE on the SSL/TLS communication phase, we are in serious problems.
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
add a comment |
As an end user, probably nothing. The very stage where you are at the communication sequence of a TLS transaction makes it so you are not really vulnerable to anything other than MITM.
Most of the discovered vulnerabilities discovered on the protocol and it's implementation itself, on the other hand, may impact the server responsible for hosting it. Even then, TLSv1 is not nearly as problematic as the older brother, SSL.
If we ever achieve RCE on the SSL/TLS communication phase, we are in serious problems.
As an end user, probably nothing. The very stage where you are at the communication sequence of a TLS transaction makes it so you are not really vulnerable to anything other than MITM.
Most of the discovered vulnerabilities discovered on the protocol and it's implementation itself, on the other hand, may impact the server responsible for hosting it. Even then, TLSv1 is not nearly as problematic as the older brother, SSL.
If we ever achieve RCE on the SSL/TLS communication phase, we are in serious problems.
answered Jan 14 at 12:33
BristranBristran
1012
1012
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
add a comment |
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
3
3
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
Not really vulnerable to anything other than MITM??? In most/many cases that would be a fatal security breakdown.
– Will
Jan 14 at 22:45
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
My other use cases is for a web crawler that I'd like to be able to crawl any websites at all, regardless of the robustness of the certificate that's there. I didn't think there'd be any exploit that would affect the crawler, but wanted to double check the thinking, since there is a negotiation, and a payload of sorts is sent back to the client. So that's why MITM isn't really a concern, for this use case at least, which I do realize is not the main question at hand ;-)
– Brad Parks
Jan 16 at 15:17
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- 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%2fsecurity.stackexchange.com%2fquestions%2f201429%2fas-an-end-user-what-risk-is-there-in-browsing-a-public-website-that-uses-tlsv1%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
"only supports TLSv1 ... but has an SSL cert installed on it that's out of date by modern security standards." - The SSL certificate has (almost) nothing to do with the TLS protocol version, i.e. the same certificate can be used with TLS 1.0 and TLS 1.2. "...or other insecure ciphers or protocols ..." - similarly, ciphers have not much to do with protocols too. While there are some ciphers introduced with TLS 1.2 the ciphers available for TLS 1.0 are also available for use with TLS 1.2. It is a bit different with TLS 1.3 though.
– Steffen Ullrich
Jan 14 at 22:28