Kim Gentes

OK, so Facebook now gives you the option of talking to their site over an encrypted protocol. Cool. Well, sorta. But not really. I am not saying using HTTPS is not better than straight HTTP web browsing, but if regular (non-technical) users think it will make their use of Facebook safer, they probably really don't understand what makes Facebook (or any website) truly insecure to them as users.

First, Secure Sockets Layer is not new.  Facebook didn't just discover it or something, it has been around since 1995 (see http://en.wikipedia.org/wiki/Transport_Layer_Security for more info).  The purpose of HTTPS (the particular implementation of SSL that is being talking about) is simply so that when you are talking to a particular website that the communications directly to that site cannot be falsely interrupted, decoded, or mimicked without someone who has a very, very high level of acumen in digital security.

However, the problem with internet security is not HTTPS usage- it is almost 99% about leading legitimate web surfers to an illegitimate site.  This means that there are people out there who try to get you to click on links that lead you to somewhere OTHER than where you expected to go. And once you are at their phoney site, they have you normally enter some personal data that they later use to exploit you or steal your identity.

It goes like this-

1. you get a link in email that looks like it is from Facebook
2. you click on it.
3. you go into the site, surf around and leave
4. you didn't realize that you had gone into a site that wasn't Facebook, and they stole your password and user login because you entered it to get into their fake site.

That above scenario happens in email scams with everything from Bank "notifications" (phoney ones) to Facebook updates to whatever.

The point is, SSL or HTTPS doesn't make that above situation any safer.  If you followed your email links then nothing appeared to be wrong, and HTTPS operating on the real Facebook won't be of any help to you while you are logging on a phoney website that is only made to look like Facebook to steal your access.

There are really two main rules that will cover about 80% (making that figure up in my head) of your problems on Facebook or any site:

1. NEVER use a link that you get in email from an organization. Instead, almost all places (like Facebook or your bank, etc) allow you to log in to their website directly, then see the notifications or items they wanted to bring to your attention. This is the MOST important safety precaution you can make on any site.
2.  In Facebook in particular, don't use Face Apps.  Apps are developer access to you and all your information. Regardless of what the app is for, they can access EVERYTHING about your Facebook account once you approve an app.  Of course, there are a few apps that people use anyways, but just know that an App can literally access any information in your Facebook context. You can see my other article on how to block Apps that may bother you.

The HTTPS thing in Facebook merely gives people a bit more safety while they surf facebook, but doesn't protect them from the above two items, which ultimately cause vastly more security and other problems.  If you aren't careful enough to note click on emails from anyone that might look like Facebook in your email, then you likely aren't watching to see if you are locked secure while surfing Facebook either.

Now don't get me wrong, HTTPS settings on your login in Facebook does make that part safer. But for most users, it is the email and other links getting you to a "supposed" Facebook location that cause more problems. And once people are in Facebook, it is the propensity to use Apps (and even spoofed bad apps as well) that poses a greater risk than actually getting thread attacks into your browser during an actual session on Facebook, in my opinion.

keep on surfing safely people...

Kim Gentes

One of the great things about today's software development culture is that competition has driven change to a feverish pace.  If you watch Google, Apple, Microsoft and the biggies, you might think things plod along relatively quick. And for those companies they do. But with huge staffs of developers they can mitigate against quality issues by planning and throwing modern techniques (and hordes of people) to the technical challenges of keeping up with smaller, nimble companies who are focused on niche markets.  The little developers have their pains- small staffs and tiny budgets mean they only have a few swings at the plate before using up the resources available will drain away.

The savior of all this was supposed to be open source. In the open source world, we would all be able to benefit from larger efforts shouldered by many, and let the specific applications be driven by those who cared about applying a great technology to a market.  So those fundamental technologies became the backbone of open source development. Things like: Linux, PHP, (Apache/HTTP to a lesser extent), Javascript, Java, AJAX,  and a cadre of other core technologies would let us all play nice and develop fast.

But what happens when one of those core technologies drops the ball?  It lands on the consumers e-foot, that's what!  The latest revision of lameness in technology land? None other than the mothership of ubiquitous programmatic lifeforce- Java! Java was lauded as the end-all-be-all language that would unite all platforms, hardware, OS, devices into a playground of loveliness for app developers. Java would bring us all together and unite our efforts to work everywhere. If Java proponents were to believed the Borg, Klingons, Ferrengi and Vulcans would be having tea parties and celebrating peace and harmony conferences to endorse Obama's nuclear disarmament agreements. Such is the hope.

Well, on March 31, the Java fiesta of loveliness was interrupted by a blip on the "what the!" radar. Turns out that Sun (the company that builds and releases the Java language, engine, clients and its updates) managed to release its update 19 of Java v6 with the profound ability to break literally every single applet that was signed by one of the largest authentication agencies in software credentialing.  Tech geeks keep on reading for gory details, but for all you folks who already want to slap me, here is the short answer.

Java programs (called applets) need to be verified as "safe". The process of verifying them and "publishing" them as secure is done through a method called "signing". This signing basically places encrypted information on to the Java applet that verifies itself by announcing its identity and a secret code.  When people use the internet and are about to use a Java applet that is "safe", their computer reads the identity and secret code from the applet. That code and identity is verified against a database at a "trusted" digital security company (companies that do this type of verification checking are called "authentication services").  If the identity and code don't match properly according to the standards at the security company database, it tells the web surfer that the Java program they are about to use is not to be trusted.  Users, understandably, react by blocking the program from running.  This is they way digital signing /security works on program applets for Java. Has for many years.

The problem is that Java recently released an update (both v6 updates 19 and 20 include this problem) that incorrectly breaks all the code signing certificates (the digital security) issued by Thawte. This is sad and funny, depending on who you are. Thawte is one of the largest digital security providers in the world. Having Java drop the ball on this is no small item. Thousands of applets all over the web are now reporting how unsafe they are! Thanks Java ! Thanks Sun!

To get the detailed skivvy on this, I went to my friend and web/developer guru Kevin Lott for the nitty gritty details. Lott says,

Java SE 6 update 19 was released on March 31. Java SE 6 update 20 was released on April 16th. Unfortunately, both of these updates are botched releases that will break all code signing certificates issued by Thawte.  The algorithum on the Thawte Premium CA is MD5withRSA, however Sun released the update with the wrong algorithum - SHA1withRSA.  This will cause the browser to prompt you with an ugly message saying "Java has discovered application components that could indicate a security concern" with the option to block unsafe components.  Naturually customers will want to protect themselves and agree to the block breaking your Java Applet application. (Kevin Lott, April 16, 2010)

What does this mean? Well, if you are using any Java applets on any of your favorite websites and they suddenly say "Java has discovered application components that could indicate a security concern"--- you might contact the company before assuming there is anything wrong. There is a good chance that Java itself is causing the problem.

The fix? Well, for users and web surfers, your best bet is to uninstall Java and go back to v6, update 18. For companies who develop applets? Encourage your customers to revert to update 18, or hope and pray that Java releases a fix before the whole web GUI world decides to move permanently away from any use of their technology.

Well, now that you have had your juicy tech update... back to the grind stone people!

happy teching,

Kim Gentes