No edition of the Black Hat conference would be complete without a few security bombshells; The ones where attendees learn that a huge swath of their digital security -- previously thought to be totally secure -- is little more than a house of cards that, thanks to some Black Hat researcher, just came tumbling down. Here in Las Vegas, Moxie Marlinspike is one of those researchers and he's here demonstrating how SSL is that house of cards. Think your implementation of SSL is secure? Think again. It's time to go back to square one. (includes podcast interview)

According to Marlinspike, it's not the SSL protocol -- the protocol used for the secure form of the Web (https) -- that's the problem. It's the majority of the implementations that are utterly insecure. This includes most of the major banks, email systems, social networking sites, and so on. Even most software update mechanisms.

To learn more about what appears to be a complete meltdown of the Web's SSL ecosystem, I caught up with Marlinspike for for a podcast interview. To listen to the interview, you can press the tiny play button in the previous sentence, click on the podcast player tab hanging off the bottom left-hand side of this Web page, or right click on the link in the previous sentence to download the MP3.

"The fundamental concept is the idea of attacking bridges" Marlinspike told me in the podcast. "The way that SSL is deployed in the context of the Web is kind of unusual. SSL is supposed to be a secure protocol. But it's very rarely encountered directly. It's almost always encountered as the result of some HTTP connection. You're using HTTP, you're browsing along, and eventually, you encounter a link that says 'Login' or 'My Shopping Cart' or 'Checkout' or whatever and you click on that and that's when you enter this SSL world. When you think about it [in this type of implementation], SSL as a protocol actually depends on HTTP as a protocol and its very security depends on HTTP and HTTP is not secure. So you have this secure thing that depends on this insecure thing and in the past and today, I've been talking about attacking SSL directly. But another way to look at it is to attack SSL before you get there by attacking HTTP instead."

So, in real world terms, what is Marlinspike talking about? How often is a session with any Web site physically started over an HTTPS connection first (where the initial request to the site is sent over an encrypted link)? Think about your own behavior on the Web. First, there are so few sites that even accept an initial connection of HTTPS. Gmail happens to be one site that does and I always initiate my connections to Gmail from an HTTPS'd bookmark. But even in the cases where a site would accept an HTTPS connection from the get go, most users never take advantage of the option. They either start by typing "www" (which defaults to HTTP) or they click on a link from a Google search result, some Web site (doesn't matter which one), an email in their inbox, etc. The glaring example is where 90 percent of your experience on some shopping site is over HTTP until the time comes to actually pay. Only then, does the shopping site send you back a page with HTTPS links on it. Everyone looks for the padlock in their browsers (these days, padlocks appear all over the place so they're useless anyway) and thinks "OK, the next thing I click on is secure. I'm good."

Think again.

So commonplace and easy to execute are so-called man in the middle (MITM) attacks that they're not even a hot briefing topic at Black Hat. When a MITM is a pre-requisite to some other exploit being discussed at Black Hat, it's just assumed by everyone in the building that that part of the exploit isn't even a speed bump. There are all sorts of MITM attacks but one of the "fun" ones is where you go to some public hotspot and start your own WiFi access point with the same SSID as the one advertised by the public hotspot's access point. Or even better, give your access point the SSID "Free WiFi." In either case, over a very short period of time, you'll get plenty of people connecting to the net through you and once you do, you are the main in the middle. You own the connection. This is a simple MITM.

There are plenty of more complicated ones. For example, Marlinspike put himself in-between hundreds of users and the sites they were visiting by running a TOR exit node. As a security measure, a lot of people use TOR to anonymize themselves and their behavior on the net. But the minute they went through Marlinspike's TOR exit node, over a 24 hour period, he collected 114 login credentials to Yahoo, 50 login credentials to Gmail, 42 sets of Ticketmaster credentials, 13 Hotmail logins, 9 PayPal logins, 9 for LinkedIn and 3 from Facebook.

How did he do it? The answer is ridiculously simple. Using a tool that he authored called SSLStrip, he watches over all the HTTP connections passing through is man in the middle and when he sees pages being sent back to end users with HTTPS-based hyperlinks in them, he intercepts them and and essentially strips the "S" off all the HTTPS links. The result? A page that was once loaded with secure links now has nothing but insecure links on it which means that any information that the user transmits as a result of clicking on those links (passwords, credit card numbers, etc.) is in the clear.

Says Marlinspike, "What SSLStrip does is it man-in-the-middle's HTTP connections, watches traffic go buy, and if you see any secure links or redirects, it just swaps those out to identical insecure links. So the user never gets upgraded to SSL. The way that most people's user experience works, they will never notice."

By now, you're asking about the all the safeguards that would normally be in place -- what Marlinspike calls the "positive feedback" that everything is OK. For example, the padlock that a browser displays in its status bar. As it turns out, that's a piece of cake too. Once there's a man in the middle, s/he owns the connection. Instead of just stripping the "S" off the the HTTPS links, he offers the end user his own secure links which in turn trigger the positive feedback that users look for when hoping to engage the Web securely.

To put icing on the cake, as the man in the middle, Marlinspike doesn't kill the connection or spoof the destination site. Instead, he just proxies the traffic back and forth so that neither end of the connection is aware of the problem.

In the podcast, I ask Marlinspike what's the consequence.

"The consequence is that your data is not secure. Basically the upshot from today is we've got all of your secure communication. You're logins. Your passwords. Your credit cards. Your banking information. Everything. All of that cannot be protected by SSL given current implementations. The other upshot is that we control your computer because there are these autoupdate mechanisms that use SSL and we can hijack them to install our own software on your computer that does whatever we want. So, we've got all your communications and we've got control over what software runs on your machine. So, it's deadly."

Deadly indeed.

And how did the Black Hat audience respond to Marlinspike's briefing? Just search "Marlinspike" on Twitter to get an idea. You'll see words like "scary" and "terrifying."

David Berlind is the chief content officer of TechWeb and editor-in-chief of TechWeb.com. David likes to write about emerging tech, new and social media, mobile tech, and things that go wrong and welcomes comments, both for and against anything he writes. He can be reached at [email protected] and you also can find him on Twitter and other social networks (see the list below). David doesn't own any tech stocks. But, if he did, he'd probably buy some Salesforce.com and Amazon, given his belief in the principles of cloud computing and his hope that the stock market can't get much worse. Also, if you're an out-of-work IT professional or someone involved in the business of compliance, he wants to hear from you.

Twitter: (@dberlind) My Facebook Page Flickr (davidberlind) YouTube (TechWebTV) FriendFeed (davidberlind) Del.icio.us (dberlind ) Me on LinkedIn Plaxo (davidberlind) Disqus (DavidBerlind) Google Profile (David.Berlind)