(for background see this hackerne.ws post)
Really, the problem here is nobody trusts the CAs. (it is kind of difficult to just assume 650 different CAs will all maintain 100% security over their cert-generation procedures)
What people seem to be looking for here is an early warning system for possible mitm *after* an initial "trusted" connection (which you can never tell for sure because even if you're browsing from a secure LAN the destination site could have been compromised, or the nameserver).
The best solution to this problem is one that will fix the problem of a trusted initial connection without relying on CAs. Of course this is difficult. But let's simplify it a bit first.
Assume for a second the internet is only two nodes: me at a desk in one room and an ethernet cable that goes into an adjoining room. I don't know who's in that other room - but I want to connect to the other end and do my banking. So how do I know if it's my bank in there or a stranger?
What do I have that I can trust right now? I have my computer, which contains (among other things) an operating system and a web browser. We won't discuss how it got there, because to discuss the origin of things ad infinitum will leave us with religion and that never solves anything.
My browser already ships with trusted information: the certificates of trusted authorities. But it's trying too hard to make everybody happy, sucking up as many different sources of trusted information as possible. In ten years we might have 6,500 trusted CAs. This won't end well.
I just want to tell if the person in the room is really my bank. What can I do to be sure?
I can ask the person in the room a secret only my bank knows, for one thing. I could have told my bank in person or over the phone, via a letter, or probably whenever I joined my bank for the first time. This would be something only I would know, not something that came with my computer.
Another way I can be sure is if I verify all the steps in the process to connect to my bank. If someone was trying to fake being the bank, they would probably have a different IP address and a different certificate. If I had a print-out with a hash of those and punched it into my browser before I made the connection, my browser would know for sure this is the bank's information and reject the connection if anything was different.
What we have here essentially is static configuration and CHAP. Combine this with PKI and you have three separate pieces of information which must be spoofed in order to successfully compromise the connection. If the person in the other room knows all of this, the bank is surely compromised anyway.
Note that this is merely a way to establish a "secure first connection". You will still need to at least have specific information about the site you're connecting to (IP and cert hash) and to be more sure of the connection have already registered and set a secret only you and the other person know.
There are technical limitations with some of this design, but if these can be worked around you should have a fairly secure connection. If you want to sleep better about PKI there should be less CAs (more like 10 instead of 650).
Monday, March 28, 2011
Thursday, March 3, 2011
universal webapp architecture
I think its funny when people have to redesign their architecture. It's like, what, you couldn't scale? Just throw some hardware at it.
Your framework had limits? Why'd you reuse it in a way that would eventually run into bottlenecks? Didn't you learn how the whole thing worked before deciding to implement it?
Your code is slowing down and bloating up, so you figure a redesign is easier than optimization? Congratulations, you've fallen victim to the worst thing you can do when faced with performance problems: throwing the baby out with the bath water.
Just optimize your current crappy system and add layers to make it get cheap performance, scale horizontally and get on with business. Redesign is usually a waste of business resources.
Your framework had limits? Why'd you reuse it in a way that would eventually run into bottlenecks? Didn't you learn how the whole thing worked before deciding to implement it?
Your code is slowing down and bloating up, so you figure a redesign is easier than optimization? Congratulations, you've fallen victim to the worst thing you can do when faced with performance problems: throwing the baby out with the bath water.
Just optimize your current crappy system and add layers to make it get cheap performance, scale horizontally and get on with business. Redesign is usually a waste of business resources.
Monday, February 28, 2011
holy ipv6, batman
i just realized my server is passing ipv6 traffic through ssh for my clients. i enabled ipv6 on a windows laptop (netsh interface ipv6 install, not ipv6 install) and told putty to connect to an ipv4 address, tunneling a dynamic socks proxy on both ipv4 and ipv6 to my remote server (which has an average ipv4 and ipv6 network with 6to4 set up for whatever my isp's 6to4 gateway is). then set up my browser to use the dynamic forward port as its proxy, and hit 'ipv6.google.com'.
BOOM. page comes up. ipv6.google.com<->my6to4box<->putty<->windows<->browser. it just friggin works! http://test-ipv6.com/ says it is indeed the ipv6 addy of my6to4box that it's seeing, so ipv4 and ipv6 really are being tunneled automatically. this is pretty cool.
NOW WHY ISN'T EVERYONE DOING THIS YET?!
(what's funny is i only tested this today because xkcd kindly informed its readership that they finally fucking set up an AAAA record which i'd been complaining about for over a year)
BOOM. page comes up. ipv6.google.com<->my6to4box<->putty<->windows<->browser. it just friggin works! http://test-ipv6.com/ says it is indeed the ipv6 addy of my6to4box that it's seeing, so ipv4 and ipv6 really are being tunneled automatically. this is pretty cool.
NOW WHY ISN'T EVERYONE DOING THIS YET?!
(what's funny is i only tested this today because xkcd kindly informed its readership that they finally fucking set up an AAAA record which i'd been complaining about for over a year)
it had to happen sometime
i predicted this years ago when my last company first thought of migrating to a 3rd party to host their mail cheaper. i don't remember if they ever implemented a strategy to back up the mail remotely, though i do remember for a while the "beta testers" had their mail sent both to exchange and gmail.
point is: don't tell me just because a company is large or reputable that the basic procedures of any IT department should be ignored. if you have data and it's important you need to keep a backup, and you need to be able to verify the backup. if you can't put your hands to a redundant offsite copy of your data it's going to vanish eventually.
to all the people that lost their mail: i feel for you. i've lost data before too because i didn't back it up. however, we do learn that most of our correspondence's history is unnecessary. nice to have "in case of emergencies", but unnecessary. do i really need those mailing list threads from 3 years ago? will that website confirmation really be necessary down the road? nah. the personal messages passed between family and friends may be missed, but i've never really "gone down memory lane" before and doubt i would in the future.
this is also the risk you take when you rely on web-only email. luckily i believe gmail allows any user to make an offline copy of their mail, but some services like yahoo and hotmail do not (unless you pay). i'd like to see a push for competing providers to mirror other providers' datasets for redundancy but that might just make them less important in the end.
point is: don't tell me just because a company is large or reputable that the basic procedures of any IT department should be ignored. if you have data and it's important you need to keep a backup, and you need to be able to verify the backup. if you can't put your hands to a redundant offsite copy of your data it's going to vanish eventually.
to all the people that lost their mail: i feel for you. i've lost data before too because i didn't back it up. however, we do learn that most of our correspondence's history is unnecessary. nice to have "in case of emergencies", but unnecessary. do i really need those mailing list threads from 3 years ago? will that website confirmation really be necessary down the road? nah. the personal messages passed between family and friends may be missed, but i've never really "gone down memory lane" before and doubt i would in the future.
this is also the risk you take when you rely on web-only email. luckily i believe gmail allows any user to make an offline copy of their mail, but some services like yahoo and hotmail do not (unless you pay). i'd like to see a push for competing providers to mirror other providers' datasets for redundancy but that might just make them less important in the end.
Thursday, February 17, 2011
why your company needs to use 2-factor security now
so this story points out one of the pink elephants in corporate security: accounts are often left open after employees leave the company. the other pink elephant they won't talk about is shared accounts.
i can't tell you how many people's passwords have been told to me by users while i was an admin. if i wasn't creating them an account i'd just be troubleshooting something and they'd just give me their password, like it was a free coupon. aside from this there's co-workers who often share passwords to get access to files locked away by strong permissions or to work on the same project for brief periods, or just for the hell of it. they don't really care about security and they don't think anyone's going to abuse the trust. but there's very little trust in real security.
so here you have ex-employees who potentially know several other employees' passwords. if all you use is a password for, say, VPN and e-mail, your company has been owned. there are case studies in how you will get hacked just by pilfering an e-mail account. so clearly, this shit needs to be locked down. you can't just rely on a password - you need another authentication factor.
don't want to pay for expensive RSA SecurID? that's fine; use VeriSign's free OpenID provider and a $5 hardware authenticator from PayPal (or a $30 version from VeriSign) and you have effective, open 2-factor authentication.
is it possible to steal someone's authenticator and get away with a similar hack? of course. but it's a lot easier for someone just to log in using someone else's credentials and escalate to wherever they want to be.
i can't tell you how many people's passwords have been told to me by users while i was an admin. if i wasn't creating them an account i'd just be troubleshooting something and they'd just give me their password, like it was a free coupon. aside from this there's co-workers who often share passwords to get access to files locked away by strong permissions or to work on the same project for brief periods, or just for the hell of it. they don't really care about security and they don't think anyone's going to abuse the trust. but there's very little trust in real security.
so here you have ex-employees who potentially know several other employees' passwords. if all you use is a password for, say, VPN and e-mail, your company has been owned. there are case studies in how you will get hacked just by pilfering an e-mail account. so clearly, this shit needs to be locked down. you can't just rely on a password - you need another authentication factor.
don't want to pay for expensive RSA SecurID? that's fine; use VeriSign's free OpenID provider and a $5 hardware authenticator from PayPal (or a $30 version from VeriSign) and you have effective, open 2-factor authentication.
is it possible to steal someone's authenticator and get away with a similar hack? of course. but it's a lot easier for someone just to log in using someone else's credentials and escalate to wherever they want to be.
Wednesday, February 16, 2011
most tech stays the same
Sometimes I get a little scared of the future. I'm not exactly a luddite but i'm pretty close to it considering i'm supposed to be some computer-whiz hacker guy. Most of my hardware is years old by the time I buy it and I keep it around until it falls apart. My software... well, i'm a Slackware user, let's leave it at that. I still don't use any programming languages other than Perl and C. And apparently I can still make a very good living like this.
That's the funny thing i'm realizing... While we always have to adapt to some newfangled apparatus, in general everything is the same. We're still using computers based on a friggin' 26-year-old processor. We're still using the operating systems designed for them. We're still programming in and using the products of languages just as old and older. While the fashion may change, at the end of the day we're still wearing pants, and still writing code that doesn't sanitize input.
Security isn't any better than it used to be. Firewalls are still relatively dumb beasts (do you know any large company that does layer 7 filtering that isn't just proxies?). Anti-virus software is about as accurate against modern obscure trojans as they used to be. It's possible that web application writers are even less intelligent than they used to be, seeing as their output is the rife fodder for a new generation of penetration testers. Hell, we're still using passwords for root accounts. (We still HAVE root accounts!?)
Probably the one thing that is quickly changing is the barrier to entry. It used to be you'd pay a hundred bucks or more for a menial dedicated server. Now four dollars US will get you 15 gigs of space, a gig of ram and 200 gigs of bandwidth on a 100mbit shared pipe. PER MONTH! You spread that hundred bucks out and you've got an impressive server farm by 1999's standards. And computers in general keep getting cheaper, meaning more kids can get their hands on a netbook and start hacking away. Pretty soon you'll see a new start-up sector dedicated to youth and college kids, who join forces and collaborate - not to write free software like Linux, but free apps for Android and web development farms.
And still, the tech remains mostly the same. Web apps (we used to call them 'cgi scripts') and their backend counterparts interfacing with relational and non-relational databases (we used to call them 'BerkeleyDB') just become the modern fashion of development, with mobile platforms being the meatiest new market to squeeze some bucks out of. But all the old standards will still be there. Some guy will still be assembling a C library for some high-speed low-latency backend app to interface with his Clojure mobile app. The devs will write some Python or Perl script to get their app staged on their workstations and hand it off to the sysadmins to run in production (with minor edits, of course). Security goons will continue to scan their networks and sites for unexplored chasms of potential vulnerability.
We'll never really reach a utopia where modern technology becomes re-invented and everything is magically better. Everything pretty much stays the same.
That's the funny thing i'm realizing... While we always have to adapt to some newfangled apparatus, in general everything is the same. We're still using computers based on a friggin' 26-year-old processor. We're still using the operating systems designed for them. We're still programming in and using the products of languages just as old and older. While the fashion may change, at the end of the day we're still wearing pants, and still writing code that doesn't sanitize input.
Security isn't any better than it used to be. Firewalls are still relatively dumb beasts (do you know any large company that does layer 7 filtering that isn't just proxies?). Anti-virus software is about as accurate against modern obscure trojans as they used to be. It's possible that web application writers are even less intelligent than they used to be, seeing as their output is the rife fodder for a new generation of penetration testers. Hell, we're still using passwords for root accounts. (We still HAVE root accounts!?)
Probably the one thing that is quickly changing is the barrier to entry. It used to be you'd pay a hundred bucks or more for a menial dedicated server. Now four dollars US will get you 15 gigs of space, a gig of ram and 200 gigs of bandwidth on a 100mbit shared pipe. PER MONTH! You spread that hundred bucks out and you've got an impressive server farm by 1999's standards. And computers in general keep getting cheaper, meaning more kids can get their hands on a netbook and start hacking away. Pretty soon you'll see a new start-up sector dedicated to youth and college kids, who join forces and collaborate - not to write free software like Linux, but free apps for Android and web development farms.
And still, the tech remains mostly the same. Web apps (we used to call them 'cgi scripts') and their backend counterparts interfacing with relational and non-relational databases (we used to call them 'BerkeleyDB') just become the modern fashion of development, with mobile platforms being the meatiest new market to squeeze some bucks out of. But all the old standards will still be there. Some guy will still be assembling a C library for some high-speed low-latency backend app to interface with his Clojure mobile app. The devs will write some Python or Perl script to get their app staged on their workstations and hand it off to the sysadmins to run in production (with minor edits, of course). Security goons will continue to scan their networks and sites for unexplored chasms of potential vulnerability.
We'll never really reach a utopia where modern technology becomes re-invented and everything is magically better. Everything pretty much stays the same.
Friday, February 11, 2011
encrypted message passing with plausible deniability
so, RedPhone is encrypted VoIP with an intermediary to pass the connection off. with this it's possible for a foreign power to force you to reveal the nature of the call. their other product, TextSecure, offers little in the way of "encrypted SMS" because they use OTR which is effectively pointless with a man in the middle. however, if you wanted to transmit a message with plausible deniability, you could do it like this.
create a store-and-forward service for anonymous message pushing and pulling. make all messages encrypted and have a set size. something decent enough for a small compressed media file. every time you connect you push an encrypted message of this size and you pull one of the same size. every single time. time between each successful communication should be something like every half hour or every hour.
the result should be that nobody can tell if you were actually sending or receiving anything because it always sends and receives something, all the time, regardless of whether you needed to do anything. you could also have it encrypt like a matroska file so you can encode multiple files, and possibly even an encryption package which only decrypts parts of the payload as determined by the encryption term used, so if you used one decryption term it decrypts an MP3 file, and another decryption term reveals secret documents. plausible deniability!
create a store-and-forward service for anonymous message pushing and pulling. make all messages encrypted and have a set size. something decent enough for a small compressed media file. every time you connect you push an encrypted message of this size and you pull one of the same size. every single time. time between each successful communication should be something like every half hour or every hour.
the result should be that nobody can tell if you were actually sending or receiving anything because it always sends and receives something, all the time, regardless of whether you needed to do anything. you could also have it encrypt like a matroska file so you can encode multiple files, and possibly even an encryption package which only decrypts parts of the payload as determined by the encryption term used, so if you used one decryption term it decrypts an MP3 file, and another decryption term reveals secret documents. plausible deniability!
Subscribe to:
Posts (Atom)