Focusing on the Man-in-the-Middle<\/h2>\n\n\n\n
In 2017, it\nwas discovered that many banking apps<\/a> from popular banks with a global presence\n(including Bank of America and HSBC) were vulnerable to man-in-the-middle\nattacks due to software not properly verifying the chain of trust. Unknown to\nany of these bank\u2019s members, attacks with access to the networks on which a\nclient was doing their banking could have posed as the bank\u2019s server and\nharvested balances, credentials, and even 2-factor authentication tokens.\nImagine having your life savings wiped out in a matter of hours, with little to\nno recourse.<\/p>\n\n\n\n As of April\n2019, tech titan Google has made an unprecedented decision that shows how\nseriously they take this threat. As policy going forward, they are forbidding\nlogins from mobile frameworks from being able to sign in to their sites and\nservices. Even though there is nothing malicious about these frameworks\nthemselves, they appear heuristically similar to man-in-the-middle attacks when\nit comes time for Google to determine if a sign in attempt is legitimate or\nnot. This is a controversial decision, but it puts security first. Going\nforward, developers are expected to transition to OAUTH tokens for federated\nlogin.<\/p>\n\n\n\n HTTP is not\nthe only protocol vulnerable to man-in-the-middle attacks. In 2018, a\nvulnerability in the Bluetooth protocol was discovered (https:\/\/www.kb.cert.org\/vuls\/id\/304725<\/a>) that allows an attacker to\nintercept Bluetooth communications encrypted by SSL\/TLS. Imagine an attacker\nintercepting communications as a user paired their phone with their smart lock.\nSuddenly, it\u2019s not so hard to imagine the risks of insecure communication not\nonly affecting one\u2019s digital life, but one\u2019s home as well. <\/p>\n\n\n\n To a\nbusiness, MITM attacks represent risk. Their reputations and profitability are\nat stake. According to the Ponemon Institute, the average cost for any kind of\ndata breach is $4.13 million. This does not necessarily scale linearly with the\nsize of the business. For many smaller businesses that do not clear this kind\nof revenue at all in a year, a single data breach can mean closing its doors. <\/p>\n\n\n\n So, how then\ncan a savvy business protect itself from this risk? How can these attack\nvectors be effectively mitigated? There are both administrative and technical\nhurdles to overcome. <\/p>\n\n\n\n Deciding as\na business on a uniform baseline policy for SSL\/TLS is an effective way of\nmaking sure individual business units don\u2019t make these decisions in a vacuum.\nThere is always a trade-off between compatibility with older devices and\nsecurity of data transfer. <\/p>\n\n\n\n A banking\ninstitution may well determine that only TLS 1.2, with only the strongest\nciphers, and Perfect-Forward-Secrecy across the board is the way to go. They\nwould also likely already be evaluating a move to TLS 1.3. To their business\nsegment, the lack of compatibility with older clients is worth the security of\nknowing that even 100 years in the future \u2013 or at least until quantum computing\nbecomes viable \u2013 this information will be kept secret. <\/p>\n\n\n\n A deli that\naccepts online orders however, may determine that compatibility is more\nimportant, and that all things considered, a data breach isn\u2019t on the top ten\nlist of things that could prove a death knell for the business. Regardless,\nwhether you\u2019re a bank or a purveyor of meats, user training is an equally\nimportant piece of the puzzle. <\/p>\n\n\n\n A recent academic study conducted by doctors from several prestigious US and UK university over 8 years found that employee training really does work<\/a>. Over the course of multiple simulations across several years employees showed decided improvement in terms of being able to identify threats and escalate them properly.<\/p>\n\n\n\n Moving on, in\norder to make effective decisions, the decisionmaker either needs to be\nknowledgeable, or be able to delegate to someone that is. For bigger businesses,\nthis might mean training users to look for the lock in their browser when\nmaking an online purchase. For the deli owner, the best decision is probably\nnot to host the online services in their nephew\u2019s basement, but rather to\nenlist the services of a professional.<\/p>\n\n\n\n For security professionals, staying current on the current threat landscape and up-to-date on the latest mitigations against these threats is paramount. In August of 2018, TLS 1.3 was finalized in RFC 8446<\/a>. With it, perfect forward secrecy is no longer a cipher-level decision, but mandated in the protocol specification. <\/p>\n\n\n\n Session-resumption,\na feature of TLS 1.0 thru 1.2, which was prone to implementation weaknesses was\nremoved entirely in favor of pre-shared keys. <\/p>\n\n\n\n One\ncontroversial aspect of TLS 1.3 that will likely hinder its adoption is that\nthere are new considerations regarding forward proxies. Many organizations, in order\nto provide gateway antivirus protection and protect against the theft of\nintellectual property, perform deep packet inspection. If you see that\ncertificates your browser trusts on a company owned device are signed not by\nthe site you\u2019re visiting, but by your company\u2019s firewall instead, this means\nthat the company is using this kind of technology. <\/p>\n\n\n\n While TLS\n1.3 can in fact be intercepted by a company for this purpose (because they\ncontrol the root certificate store on the endpoint as well as the route the\ntraffic takes), many existing software implementations relied on the TLS 1.0 \u2013\nTLS 1.2 handshake in order to provide this deep packet inspection. Companies in\norder to support TLS 1.3 at the very least will have to upgrade the firmware on\ntheir devices, and in some cases even purchase new hardware in order to inspect\nthe traffic in a different way. This mostly affects companies using implicit\ndeep packet inspection. Explicit proxies instead rely on CONNECT messages,\nwhich operate largely the same way with TLS 1.3.<\/p>\n\n\n\n This practice of intercepting HTTPS communication is controversial<\/a>. It intentionally breaks the foundation of encrypted communications and introduces additional points in the chain where an attacker could insert themselves towards malicious ends. Simultaneously, being able to inspect this data forms the bedrock of many organizational policies that inspect payload data for things like sending social security numbers, credit card numbers, or protected trade secrets via unexpected channels. Much like Google\u2019s decision to disallow authentication from well-intentioned mobile frameworks for the betterment of overall security, it would be unsurprising if deep packet inspection itself faces a reckoning in the future.<\/p>\n\n\n<\/span><\/span>\n\n\n Finally, with public key pinning losing traction, one of the best ways to protect your users is to employ HSTS<\/a>. This technology works by a browser-based cache that maintains a database of visited websites. If the website identifies itself as leveraging HSTS, the browser will disallow insecure communication to that site. No connections can be made in the future via HTTP, crippling SSL stripping attacks. (Assuming of course, that the user is not being attacked on their very first visit to that site from their computer).<\/p>\n\n\n\n You may also\nconsider adding your website to the HSTS preload list, which is maintained by\nGoogle and used by all the major browsers. Even if an internet user has never\nvisited a given site, as long as it\u2019s on the list their browser will know to\nforce an HTTPS connection. This effectively shuts the window on a very narrow\nattack vector that presents itself upon a user\u2019s first visit \u2013 before they have\ndownloaded the HTTP header. <\/p>\n\n\n\n![\"man-in-the-middle](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/11\/man-in-the-middle-attack.png\")
<\/figure>\n\n\n\nDefending against the Man-in-the-Middle<\/h2>\n\n\n\n
TLS 1.3 vs the Man-in-the-Middle<\/h2>\n\n\n\n
Final Thoughts<\/h2>\n\n\n\n