Dan Kaminsky calls for a few good hackers to secure the web Dan Kaminsky, chief scientist for the cybersecurity firm White Ops, reknowned for fixing flaws in the DNS system, has a new project push on and he's looking for coders to lend a hand. He's currently hosting a four-day hackathon to build a set of tools designed to fix some of the most basic flaws and faults in IT security. …
Virtualisation has been proven to not be very effective over and over again. Essentially even if it works perfectly you just have a "separate computer" which still needs to communicate with other computers. You can't fix one of the most prominent problems, an SQL injection, that way, for example.
Then storing a key on a separate machine (i.e. one owned by Amazon) you may not be able to get them externally. However since you probably get to a password database through the web app... which needs to authenticate you, it's likely you'll get that secret key used to encrypt the password database along with the database.
You could actually do something Kaminsky-like more for security if you'd store webpages in DNS. Since DNS is extremely well cached, a DOS wouldn't be so bad, most users would still get the cached copy.
There's also the obvious solution of eliminating complexity. Every line of code that's not there cannot be a bug and cannot be a security problem. Every framework brings you new bugs, and if you load javascript from other servers you don't own, those servers will own you and your users.
Not so bothered about DNS. That's a back-end infrastructure issue and redesigning a set of name-to-IP lookups isn't exactly tasking, it's just awkward, and there are plenty of things we already have that we're not using (DNSSEC etc.).
But can someone, please, for the love of <deity>, fix email?
Spam email, fake email, unencrypted email, etc. That has a real-world effect and has absolutely no solution at the moment, besides rubbishy, non-guaranteed bolt-ons to existing SMTP protocols (SFP, DKIM, etc. but still no proper end-to-end encryption).
Why does DNS not hold a set of public keys for each domain that are used to encrypt email to that domain by all email servers (and unsigned email is just discarded)? DKIM isn't the same, that's more like a signature and the content still isn't encrypted (and certainly not guaranteed to be past the first hop).
High-end DNS-based attacks using VALID DNS DATA like the Dyn hack don't interest me at all. But email still be open to a network sniffer at any point along the way to your destination is so 1980's that it's just laughable. And people STILL think that email is secure. It's time we actually made that assumption true.
And if we can make it so that you have to prove ownership of the private key (by signing some kind of nonce value) for the domain you CLAIM to be sending FROM, we can cut fake email out the second it arrives without having to guess based on IP address (which is just silly in an IPv6 world).
"And if we can make it so that you have to prove ownership of the private key (by signing some kind of nonce value) for the domain you CLAIM to be sending FROM"
I'm not sure about claiming a private key for the domain but a private key for the actual user ID is a different matter. That would be right here on my own device*.
Oh dear. That makes webmail a bit of a problem doesn't it; yet another example of security being sacrificed to convenience. That sacrifice is, of course, one of the main sources of our problems. As insecurity brings inconvenience we should gradually see a rebalancing act sometime.
*Yes I know. The device might be pwned. But the pwning is so often by faked emails that there's a vicious circle that needs to be broken. Do you have any alternative suggestions? Standing there just pissing on everyone else's ideas without having any of your own is such an unattractive pose.
The email sending machine should NOT be your own machine, unless you run SMTP servers on static IP advertised as mail servers anyway.
The mail server is what has the authority to send email as your domain, not the users. And user's communication TO the SMTP server of their choice is easy to prove and secure already (TLS secures single connections like that).
No home user should be using mailservers on dynamic IP's or not going through their ISP mail server / webmail provider mail server - that's part of the problem, and their emails are already marked as junk by places like Spamhaus (that keeps a policy blocklist of ISP dynamic IP ranges for that purpose) and most mail providers.
So, no, not the user. The mail server at each end. How you send/receive email from your mail server of choice is already easy and probably already secured by TLS.
Spam email, fake email, unencrypted email, etc. That has a real-world effect and has absolutely no solution at the moment
Span is not a technology problem, it's a peolpe problem. As such, any technological attempt to fix it will necessarily fail.
Fake email is fixed by the technologies you mentioned - and you can see by the slow uptake that the bigger problem is that most people just don't care. Implementing SPF takes around 30 seconds for a simple domain[1]. Any domain not publishing a record is demonstrating how much they care. And anti-spoofing isn't an all-or-nothing affair; every domain that published a record, every server that puts a filter in place makes spoofing that little bit less viable.
Unencrypted email? We've had email encryption for *years*. Any MTA of note has the ability to use the STARTTLS verb, meaning in-transit email is always encrypted. This can be either opportunistic (encrypted, but vulnerable to MiTM) or verified (requires a publicly-trusted certificate) - and yet many, many domains just don't use it at all, even if they support TLS on inbound email. Until you can get people to care about encryption, you won't see it in many situations.
As for end-to-end encryption, we;ve had that for years as well. It's really not difficult. And yet the only encrypted email I've ever received has been as part of my testing; in practice, just about no-one cares enough to swap keys. This isn't a technology problem, it's a people problem.
Why does DNS not hold a set of public keys for each domain that are used to encrypt email to that domain
You don't need DNS for that. All you need is a certificate. And yet hardly anyone gets one.
But email still be open to a network sniffer at any point along the way to your destination
It really isn't, unless you're talking about sysadmins who don't care at all.
Vic.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
