We know, it’s just that DNSTLS didn’t sound as nice.
This week, the mighty Google announced that it would be experimenting with the use of DNS-Over-HTTPS (aka DoH) in the next version of the Chrome browser (release 78).
Now all of our readers will no doubt be aware of many of the functions of DNS, not least converting web addresses/hostnames into IP addresses so that they can be reached. What many might not realise is just how complicated DNS is under the hood, especially in complex environments, like, err, The Internet.
Originally a regular part of SysAdmin duties, supported by the legendary O’Reilly book, DNS and Bind, like most IT Operational and architectural duties, DNS has created a swathe of specialists who speak in a language that is very difficult for the casual observer, including IT colleagues, to understand.
This means that any changes to the way DNS works can and will have major ramifications for Netizens everywhere.
One of the biggest issues about DNS is that request and response details are sent in clear text over the wire. This is a good thing for Enterprise IT staff who can use tooling to examine traffic flows, block requests and rewrite requests using load balancers and the like. It can also be used by miscreants to monitor traffic (surveillance before an attack) and redirect users to malicious sites which host nasty malware or other phishing content.
DNS-over-HTTPS has been under discussion for some time and had its own RFC-RFC8484. If you want to get an insight into how complex this is, just have a quick scan of the RFP and any of the other RFPs referenced therein. This has been floating around since the middle of last year and is now gaining momentum with not just Google but also by Mozilla in Firefox and looks sure to become very widely adopted in the coming year.
When you add to this the adoption of TLS1.3 which is very difficult to intercept, decrypt and identify malicious traffic, you can see the potential massive headache on the horizon for Enterprise security and networking types.
There are companies big (Cisco) and smaller (Barac) who have designed innovative solutions to detect (with a high degree of accuracy) malicious traffic within encrypted traffic without actually decrypting it. Sounds like voodoo huh? Yes it does but we have seen the Barac solution in action and it really works well.
What is sure is that the Enterprise will have to stand up and tool up to be able to do something smart about the forthcoming encryption headache, and fast.
This week was the usual Patch Tuesday malarky, in which Microsoft patched some 80 security holes. As ever the venerable B. Krebs Esq (we are truly not worthy) has covered the patches in exquisite detail, which saves us the bother.
There are however a couple of patches in the announcement which have grabbed our attention. They are patches for vulnerabilities in the gift that keeps on giving, RDP. They have piqued our interest because this week also saw the announcement by Rapid7 that it has released a community developed exploit model for BlueKeep (CVE-2019-0708) for the Metasploit framework.
You will recall that BlueKeep and derivatives are being used against RDP servers and in the RDP code that controls the management consoles of HyperV. Now that a Metasploit module is available, what could possibly go wrong? We have said it before and repeat; If you have public facing RDP servers make sure that they are patched and make sure that there aren’t any squirrelled away, sitting in a cupboard for years because there be dragons.
The good news is that ITC’s crack team are on hand to discuss the above or any other security issues with you. Contact us at: [email protected] or call 020 7517 3900.
Friday the 13th and a Full Harvest Moon, watch out, there be daemons about.
