7

I work with a company that has several web applications available to its customers via HTTPS. Recently, client browsers will not access these web applications due to the HTTPS connection being made via SSLv3 when TLS 1.0 was disabled during an of audit. I understand SSLv3 deprecation is primarily in response to POODLE (SSL3 "POODLE" Vulnerability) as of June 2015 (https://www.rfc-editor.org/rfc/rfc7568). TLS 1.0 is not officially deprecated, but seems to be discouraged (e.g. by NIST for the US government, see http://www.nist.gov/itl/csd/tls-043014.cfm, and also at this question Should I disable TLS 1.0 on my servers?).

For these particular web applications, the data is not sensitive to the user or the company, so data confidentiality is not a big issue. However, are there other risks? For example, if users degrade their browser security to accept TLS 1.0, are they at greater risk from a man-in-the-middle attack from other sources? Alternatively, is the company at greater risk from having its server impersonated as part of a man-in-the-middle attack? From a layman's or manager's perspective, what are the risks to the user or company from continuing to use TLS 1.0?

EDIT: The specific cipher suite used is TLS 1.0 with RSA server key for asymmetric exchange and AES 128 bit for the session key. MAC is via SHA-1.

Improve this question
6
  • Just slap on cloudflare or similar and move on
    – Neil McGuigan
    Nov 23, 2015 at 18:59
  • 1
    @NeilMcGuigan - maybe - the company has some access control requirements above-and-beyond industry standard, so difficult to slap anything on without a close review against compliance commitments.
    – Stone True
    Nov 23, 2015 at 19:05
  • 1
    SSLv3 is completely broken. Because it does not support extensions it cannot be fixed. Browsers must not support sslv3 for sites where confidentiality and/or authenticity are needed. I suggest you either upgrade to modern crypto or make the site cleartext only.
    – Z.T.
    Nov 23, 2015 at 19:30
  • This question is very similar to security.stackexchange.com/questions/106310/… .
    – Stone True
    Nov 23, 2015 at 21:11
  • If data confidentiality isn't an issue and you're unwilling to upgrade to a secure protocol, why not just go with HTTP instead of HTTPS with an insecure SSL/TLS layer? That way you avoid asking all clients to accept an insecure protocol on other sites which might care about data confidentiality.
    – user2313067
    Nov 23, 2015 at 22:04

2 Answers 2

Reset to default
1

This version of the SSL protocol, was officially release in late 1995 by Netscape after the discovery of serious vulnerabilities in the previous version (SSLv2). It is, therefore, obsolete, and it contains, as well, various flaws. For instance:

  • No support for SHA256, SHA384 and AEAD (Authenticated Encryption with Associated Data) with GCM ciphers.
  • No Elliptic Curve (EC) support and therefore no Forward Secrecy (FS).
  • More recently, in October of 2014, it's vulnerable to a new attack named POODLE (Padding Oracle On Downgrade Legacy Encryption). Padding Oracle attacks surfaced in 2001 and explore the fact that [only] in CBC (Cipher Block Chaining) mode, the padding is not protected by the integrity validation mechanisms of TLS -- i.e. MAC (Message Authentication Code). A malicious person can, thus, perform a Man-In-The-Middle (MITM) attack and force the downgrade of the protocol version, which some browsers voluntarily accept. This type of protocol negotiation is needed to synchronize both parties.

If the user becomes the victim of a MITM attack, an attacker can simply use the trust that the user has in the server to create a phishing page, and possibly steal their credentials or some other sensitive information from the company.

Improve this answer
3
  • 1
    The answer does not add much to the research in the links in the original question. I am after a layman's explanation on the risks. Question edited to reflect this.
    – Stone True
    Nov 23, 2015 at 19:56
  • 3
    (Note this answer was when the question was only SSL3 not TLS1.0.) SSL3 does have DHE for forward secrecy, you don't need ECDHE for that.
    – dave_thompson_085
    Nov 24, 2015 at 1:16
  • Also see Loren Weith's Differences Between SSLv2, SSLv3, and TLS. It lists protocol risks for TLS 1.0 and below. Its an older document, so its missing some of the more recent attacks and the newer protocols.
    – user29925
    Nov 2, 2016 at 2:30
-2

If you don't use ECDSA certificate, and use RSA certificate AND you do not use DHE or ECDHE cipher, then anyone at the Starbucks you are at can view, review, or redirect your request. If you use a RSA certificate, but have DHE or ECDHE turned on, they cannot review your information while at that Starbucks. If none of these are configured correctly, the government (pick any one) can spy on your traffic.

If this stuff is not important to you:

  1. you do not have a form on your website
  2. you don't care if someone else can track where on your website your visitors click through to
  3. you don't accept credit cards on your website
  4. you don't care if the government tracks your users access to your site

Then don't even bother with TLS encryption. Just host HTTP stuff.

If this stuff is important to you:

  1. You don't want 3rd party tracking your users traffic
  2. You don't want a government to monitor and possible block (if content offends that government) your content
  3. You care about your users privacy while surfing your site
  4. You offer a form for them to fill out and submit
  5. You accept credit cards on the site

Then turn on TLS on your website

Improve this answer
5
  • I think this answer would be acceptable if edited to make it a little less "techie", with a layman's description of a downgrade attack.
    – Stone True
    Dec 10, 2015 at 16:25
  • How would someone at Starbuck's review traffic encrypted under an RSA key without the RSA server key?
    – Stone True
    Dec 14, 2015 at 15:42
  • RSA key does not guarantee someone on a shared network cannot eavesdrop on your connection. Only pre-shared keys and Perfect Forward Secrecy (PFS) can do that (see also, DH protocol). By design, 802.11(a,b,g,n,ac) is on a shared (single collision domain) network. Anyone can open a wireshark terminal and monitor EVERYONE'S traffic on that network.
    – EagleEye208
    Dec 14, 2015 at 18:43
  • I do not think anyone simply eavesdropping on the WiFi can decrypt the HTTPS using only information gathered via eavesdropping in a properly implemented and patched system. If you think otherwise can you please provide a reference? You are correct that RSA key does not provide Perfect Forward Secrecy, but that means that future and past session keys cannot be derived and decrypted even if the private key is lost, but the private key must be compromised first.
    – Stone True
    Dec 15, 2015 at 14:44
  • The link from media.palonetworks is about decrypting SSL traffic from a work network that the client browser is on, which is a very different situation than Starbucks. There are several ways to decrypt SSL if you control one side of the network, including elliptic curve implementations of the asymmetric key.
    – Stone True
    Dec 15, 2015 at 18:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .