The LuxSci FYI Blog

by Erik Kangas, PhD, CEO

Posts Tagged ‘https’

Fred is a busy small business CEO. He hired a cheap developer online to setup his secure medical web site for him. The developer got an SSL certificate and setup pages where patients can make appointments and the doctor can receive patient requests and notices, “securely”. However, the developer didn’t have any real training in security, none in HIPAA, and as a result, PHI was being sent in the clear, there were no audit trails or logs, SSL security was not enforced, and may other serious issues plagued the site. The worst part— No one knew.

Luckily, Fred was made aware of the situation before a serious security breach happened (that he knew of); however, he had to re-do the site from scratch, more than doubling his time and money costs.

Creating a web site that has “secure” components requires more than slapping together some web pages and adding an SSL Certificate. All such a certificate really does is create a thin veneer of security — one that does not go very far to protect whatever sensitive data necessitated security in the first place. In fact, naive attempts at security can ultimately make the data less secure and more likely to be compromised by creating an appetizing target for the unscrupulous.

So, beyond paying big bucks to hire a developer with significant security expertise, what do you do? Start with this article — its purpose is to shed light on many of the most significant factors in secure web site programming/design and what you can do to address them. At a minimum, reading this article will help you to intelligently discuss your web site security with the developers that you ultimately hire.

Techniques for fighting mis-issuance of TLS certificates

The web has reached the tipping point where encrypted traffic – connections protected by HTTPS, which is HTTP over SSL/TLS – has overtaken unencrypted (HTTP) traffic. There are many reasons for this change, variously called HTTPS Everywhere or Always-On SSL, which we described in a previous FYI blog post. While this move certainly improves the security and privacy of interactions on the web, there still remains the Achilles’ heel of this ecosystem – the problem of mis-issuance of cryptographically legitimate certificates to rogue site operators. This blog post describes recent steps taken to guard against such occurrences, using techniques which can raise the necessary alarms before much harm propagates.

The Achilles’ heel of internet security is the mis-issuance of cryptographically legitimate certificates to rogue site operators.

The entire edifice of SSL/TLS-based security rests on certificates issued to the legitimate operators of websites, so that browser indicators (the secure lock icon, for example) based on various cryptographic checks can reassure users that they are communicating with their intended destination. Mis-issued certificates, whether available through lax procedures at a certificate authority (CA) or by a malignant act, removes that critical trust. A browser’s cryptographic checks cannot distinguish a duly-vetted legitimate server from a man-in-the-middle that has improperly obtained a cryptographically valid certificate. The latter might arise owing to the (mis)placed trust in a compromised root CA embedded in the browser or one issued by a corrupted intermediate CA that is in a legitimate chain of trusted certificates. This is, for example, why Google is reducing trust in SSL certificates issued by Symantec and why even Microsoft is the latest and last browser vendor to no longer going to trust anything issued by the WoSign/StartCom certificate authorities.

Some CAs make mistakes and fix them; some have a habit not well controlling certificate issuance. This seriously damages our trust in a secure internet.

Given the changes in the Internet landscape over the past five years, we feel it is time to revisit these topics. The technical details described in the earlier posts remain unchanged. What has changed, though, are the traffic patterns for HTTPS-based communications, additional vulnerabilities arising as a consequence and ways to mitigate these. This post will provide a general overview of certain changes in the Internet landscape over the past few years, while subsequent blog posts will describe some of the topics identified here in greater detail.

Web site forms are ubiquitous. Every site needs them to engage their visitors, collect information, makes sales, etc. They are easy to add to your site, but not necessarily easy to do right.

Make a quick web form using some generic web site authoring software and put it up on your site and it may work, but you also may have serious issues:

Incomplete Forms. Users submitting incomplete forms — e.g. not filling out all of the important fields

Invalid Input. Users not entering the “right” information — e.g. not actually putting an email address in the email address field

Form Spam Bots. Automated programs may fill out and submit your forms … sending you junk in the form of gibberish or web site URLs they hope you will visit and buy stuff from.

Form Insecurity. If your from collects any kind of sensitive information … from passwords to medical data … it could easily be setup incorrectly and allow phishing attacks or data leakage.

Stale Forms. You updated your form … but someone just somehow submitted the old version which is not even on the Internet anymore!

Connectivity/Server Issues. You don’t want your users to give up because their network is down or your site is down for a few seconds.

All of these problems impact the success of your site — causing everything from annoyance to the inability to contact your sales leads to breaches of privacy. Fortunately, it is not really hard to plug these gaps and have a solid, productive, and secure web form.

Only allow secure (over https / SSL) web connections from users to its servers, and

Make sure that all email traveling between its servers over the Internet uses SSL so it can’t be eaves dropped upon.

This is generally a very good thing. Its always nice when companies catch up to normal standard procedures by improving their policies. This makes the Internet an incrementally more secure and safe place.

Just be careful not to give them too much credit as this is really a case of playing “catch up” and not doing anything new or special.

SSL certificates are pervasively used on the Internet for securing all the data sent between servers, devices, clouds, phones, computers, etc. SSL certificates are intrinsic in the encryption of communications using “SSL and TLS” (how do these work?What is the difference?) — you can’t have secure communications without them!

In this article, we answer many common and not-so-common questions about SSL certificates.

Update – January, 2015. SSL v3 should be turned off. RC4 is now weak and should not be used anymore, even as a work around to the BEAST attack. LuxSci recommends to use TLS v1.1+ and NIST-recommended ciphers. The BEAST is not really considered a significant vector (even with TLS v1.0) compared to other things, anymore.

Update – April, 2012. openssl v1.0.1 is out and it supports TLS v1.1 and v1.2 which help mitigate this attack. All web sites hosted by LuxSci now use this updated software and are safe from BEAST. LuxSci recommends using a web host which supports TLS v1.1 and v1.2 for secure web connections.

—-

SSL v3 and TLS v1 are subject to a serious exploit, according to a recently published attack mechanism (called BEAST). This sounds foundation-shattering and kind of scary. When people see this, as when we did, the first panicky questions that arise are:

What is really affected?

How serious is it?

What can I do to protect myself?

How does the BEAST attack actually work?

After researching this issue, we have digested what we have found and produced this article to answer all of these questions for you.