Archive for the ‘web sites’ Category

Science Fiction Literature: Rebooted?   2 comments

John Scalzi is rebooting H. Beam Piper’s classic, Little Fuzzy.

You better get this one right, John.  Like, Peter Jackson does “The Fellowship of the Ring” right, not Peter Jackson does “King Kong” right.

Posted April 7, 2010 by padraic2112 in books, science fiction, web sites

Information is Beautiful   2 comments

‘Nuff Said.  Check out the whole site.

Posted April 6, 2010 by padraic2112 in math, science, web sites

Nerd Productivity Down 20% Today   Leave a comment

Today’s XKCD is probably going to be the single biggest non-virus outbreak related productivity killing event of the year.

Posted April 1, 2010 by padraic2112 in web sites

Nifty Widget – Readability   Leave a comment

Lane Kenworthy over at Consider the Evidence posted about this neato little web widget: Readability.

Choose the font style and size and the margins you prefer. Then drag a Readability link onto your Bookmarks toolbar. Then, whenever you’re at a blog post you’d like to print (to pdf or hard copy), just click once on your new Readability toolbar button and the post is quickly formatted to print. Text and graphs in; ads and other junk out.

Thank you, sir!

Posted March 11, 2010 by padraic2112 in research, web sites

Facebook Connect: Yeah, It’s Like Dat, Yo.   Leave a comment

Dan Wineman over at Venomous Porridge offers this tidbit:

This is called Facebook Connect, and it’s a very bad thing for security and user education. Teaching people to check that the URL starts with before logging in is useless, because Facebook wants its users to log into anything that vaguely looks Facebookish, and it’s training them to do so. How is anyone expected to distinguish Facebook from a phishing site masquerading as Facebook, when Facebook Connect looks and acts like a phishing site by design?

That’s indeedy a very good question, Dan. Undoubtedly people aren’t expected to distinguish Facebook from a phishing site, because Mr. Zuckerberg doesn’t think about security any more than he thinks about privacy.

Posted February 16, 2010 by padraic2112 in security, tech, web sites

Shorter Answer, Ivan   1 comment

I just read Ivan Ristić’s slides for his talk on “How to Render SSL Useless“, found via Luke O’Conner’s blog.  Thanks, Luke!

(spoiler: Here’s the shorter answer: if you use SSL/TLS, you’re probably not using it for the right reasons and you’re probably not getting the level of security you think you’re getting, because you’re probably doing it wrong.)

Ivan’s points boil down to this: SSL/TLS, by itself, is secure.  It’s all these implementation details that render it insecure in practice.  Ivan then offers eleven areas where SSL is “broken” in practice.

Here’s my issue with the slides: some of them don’t detail problems with SSL at all, and the other half are built into the design of SSL itself.

Let’s go through the slides by point.

Ivan’s first contention is that self-signed certificates are bad.  Ivan argues that they’re insecure, they teach users to ignore warnings, and that it’s cheaper to get a “real” certificate than to use a self-signed one anyway.

Well, a self-signed certificate is certainly differently secure than one signed by a root CA, but as to whether or not it’s less secure or insecure, that’s a completely different question (trusted authorities and exploitation scenarios deserve their own post, so I’ll leave it at this for now — edited to add — thank you, Ed Felten, now I don’t need to write this up).  The second contention is just silly, users don’t need to be trained to ignore warnings, they do it already.  The last is at best incomplete.  It requires a certain level of skill to deploy a service that relies upon a self-signed certificate, so saying “you have to maintain it” should be considered as part of the cost is mostly pointless.  You have to maintain any certificate, whether you sign it yourself or pay Verisign to sign it for you.  If I have to pay Bob the Apache Wizard to maintain my site and Bob knows how to generate a self-signed cert, it’s going to be cheaper for me to have Bob sign the cert than it will be for me to pay Verisign to do it, because Bob is going to get his salary (or his packaged SLA payment) either way.

Ivan’s second contention is that private certificate authorities are bad.  The logic follows mostly along the lines of the previous point… it’s better for you to pay someone else to do this for you than it is for you to do it yourself.  Now, he has something of a point here.  Building a CA isn’t the same as self-signing a certificate, it takes a higher degree of knowledge to build the thing properly.  I would imagine that there are a number of CAs out there that are unnecessary and they could be easily covered under one of the existing root CAs.  However, there are any number of completely legitimate reasons for running your own CA, and in any event I don’t think one-off CAs represent a big threat to the overall infosec domain.

Oh, and against both previous points: for-profit root CAs have issued insecure certs before, why should we trust them?

Points 3, 4, 8, 9, and 10 are all basically the same point: if your site needs to be encrypted some of the time in transmission, it really needs to be encrypted all of the time, period.  This is a good point (really should be a single point with examples, though), and I’m more or less with Ivan on this one, although I understand why it isn’t always the case.

Point 7 is that SSL sometimes isn’t used at all when it should be.  Not sure why this belongs on the list, that’s not a problem with SSL implementation, per se.  And I personally haven’t seen an unencrypted site that handles sensitive data in a long while, so I don’t know how germane it is anymore.

Point 11, and to a lesser extent 5, aren’t so much problems with SSL as they are problems with the couplings between SSL & DNS, pushed through the lens of user expectations.  DNS has had its own problems.

Finally, point #6 (using an EV certificate, as opposed to a normal SSL certificate) illustrates the problem I have with computer security engineering professionals.

Now, I haven’t seen the talk and I haven’t read any of Ivan’s blogging (I should, and I’m adding it to my blogroll now), so I can’t say that this is fair, but just reading the slides, here’s how I interpret the underlying context of this talk:

“SSL is totally secure, if you are using it in the totally most secure way and no other way, because we designed it to be totally secure if you use it in the totally most secure way.  Oh, but we also made it so that you could use it in all of these other ways, but DON’T DO THAT because you ruin our perfect design by using it in the non-perfect way!”

There’s a reason why I switched my research focus from infosec to disaster/crisis management, and this is it.  Information systems security designers have a tendency to draw a box in their head, and design a system that is secure inside that box.  If you use the tools they provide within the boundaries of that box, you’re golden, and if you don’t, you’re probably screwed.  But that’s not on them because they can only design out to the edges of the box.

The problems with this approach are that most systems don’t fit inside that box, the box itself often sits on top of a completely insecure table, and often the box itself has lots of little holes in it that are punched into it for various reasons.

Ignore those reasons!  Don’t use that functionality!  It’s bad!  But it’s necessary, that’s why we put it in there!  But you’re probably not doing it right, and it’s not necessary for you, so just pay someone else to do it!

If setting up your own CA is bad, then why is it good to have multiple root CAs?  Shouldn’t there be just one?  (no)

If EV certificates are the best, why do CAs offer regular certs?  (because)

If using incomplete certs is a problem, then why is it possible to generate an incomplete cert in the first place?  (because not all certs are certifying the same thing)

Heck, if self-signed certs are bad, then why do you have the ability to generate them in the first place?  (because in most practical cases, you’re looking for session security, not authoritative identification).

Posted February 16, 2010 by padraic2112 in information science, security, software, tech, web sites

Hey, Buddy, Can You Spare $15,602,022,489,829,821,422,840,226.94?   2 comments

A very oversimplified cost estimate for the Death Star over at Gizmodo.

Of course, this is ridiculous.  If you were building a Death Star, you certainly wouldn’t bother trying to schlep the raw materials up out of the gravity well of the Earth.  You immediately cut $12.79 septillion out of your cost estimate if you just start mining asteroids.  That’s an almost 82% reduction out of this budget, right there.

Come on, Gizmodo.  You can’t give a guy huge nerd points when they miss such a blatantly obvious scrounging opportunity.

Posted February 4, 2009 by padraic2112 in humor, noise, web sites