Posts Tagged ‘HTTPS’

« Older Entries

HSTS RFC Finalized

Wednesday, November 21st, 2012 | Bruce Morton

HTTP Strict Transport Security (HSTS) has been finalized and published as RFC 6797.

The purpose of HSTS is to allow a website to declare to complying users’ agents that they should interact with it using a secure connection such as HTTPS.

In order to implement HSTS, a website must have a statement in its header, such as:

  • Header always set Strict-Transport-Security “max-age=31536000; includeSubDomains”

When a complying browser sees this header, it will take any insecure link and turn them into secure links. For example, http://www.example.com would be modified to https://www.example.com. If the connection cannot be secured, the browser will show an error and not allow the user to access the site.

In the above example, the maximum age for HSTS is set at 31536000 seconds (12 months). This can be changed to other periods and will keep on being updated every time the browser accesses the site.

HSTS-complying browsers include Google Chrome 4+, Firefox 4+ and Opera 12.

I would like to congratulate Jeff Hodges, Collin Jackson and Adam Barth for their work in completing this standard.

Tags: , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »

Facebook Steps up SSL Game

Tuesday, November 20th, 2012 | Bruce Morton

A year and a half ago, I wrote a blog, Nice Try Facebook. This was my response to Facebook’s turning on of HTTPS for users. Probably a response to mitigate the new Firesheep attack. (BTW, happy second birthday Firesheep; more than 2.4 million downloads in two years.)

My issue with Facebook was the HTTPS feature was off by default. Users needed to “opt-in” and take several steps to turn it on. It also was provided on a best-efforts basis and there were some applications that were not supported.

The good news is Facebook has just released a blog stating that they are now “Rolling out HTTPS for all Users.” Per the blog, the feature will be available this week for North American users and then rolling out to the rest of the world.

If you can’t wait, you can turn on HTTPS by going into Facebook’s Account Settings, then Security, and enable Secure Browsing.

Tags: , , ,
Posted in Secure Browsing | Add Comment | No Comments »

HTTPS Everywhere 3.0

Thursday, October 11th, 2012 | Bruce Morton

The Electronic Frontier Foundation (EFF) has released HTTPS Everywhere 3.0.

EFF and the Tor Project created HTTPS Everywhere to make it easier for people to keep their usernames, passwords, and browser histories secure and private.

The idea was inspired by Google’s encrypted search option.  HTTPS Everywhere helps secure specific websites. The latest version has added 1,500 more sites, which bring the total protected sites to about 2,900.

EFF claims the software is used by more than 2.5 million people and should encrypt 100 billion page views in 2013. If the software vendors implement the technology in their browsers, the number of protected pages views could be staggering.

HTTPS Everywhere is available for Firefox and Chrome.

Tags: , , , ,
Posted in Secure Browsing | Add Comment | No Comments »

Summarization of CRIME Attack on SSL

Tuesday, October 2nd, 2012 | Bruce Morton

I’ve written a few blogs on CRIME, but now that Juliano Rizzo and Thai Duong have presented CRIME at Ekoparty 2012, I thought a summary is due.

CRIME is short for “Compression Ratio Info-Leak Made Easy.” In their presentation, Rizzo and Duong reminded us that HTTPS provides confidentiality, integrity and authenticity; however, CRIME decrypts portions of an HTTPS message, such as a cookie, which can lead to the victim’s session being hijacked.

As previously stated, the CRIME attack takes advantage of compression. Compression is used at many levels and the speakers discussed TLS compression, SPDY header compression and HTTP response gzip compression.

If we compare plain text, encrypted text and encrypted compressed-text, you might think that we are going from least secure to most secure. But that’s wrong. If an adversary can trick you into compressing and encrypting a message of his choice, you could be revealing sensitive information in another part of the message, such as a cookie header.

(more…)

Tags: , , , , , , ,
Posted in Secure Browsing | Add Comment | No Comments »

CRIME Attack on SSL/TLS

Monday, September 10th, 2012 | Bruce Morton

The security researchers who brought us BEAST now have a new SSL/TLS attack: CRIME. I would like to know what the acronym CRIME stands for, but we’ll probably have to wait until Juliano Rizzo and Thai Duong present their work at Ekoparty Security Conference later this month.

Little information about the attack has been published. The attack exploits an SSL/TLS feature that is used to implement HTTPS and affects all versions of SSL and TLS. The attack is performed by an agent that needs to be loaded on the victim’s browser. The attacker must also be able to sniff the victim’s HTTPS traffic.

The attack was successfully tested on both Mozilla Firefox and Google Chrome browsers. Mozilla and Chrome have already prepared patches, but have not yet been released. My assumption is the security researchers advised all browser manufacturers of the attack and that patches will be prepared for all susceptible.

As a publicly-trusted CA, the good news is that this is not a CA or a certificate attack. It is a SSL/TLS protocol attack that will be mitigated with new software releases. The solution will not impact the SSL certificates that you have purchased from your certificate provider.

We’ll provide more information after Ekoparty.

Tags: , , , , , ,
Posted in Secure Browsing | Add Comment | No Comments »

Living with HTTPS

Friday, July 20th, 2012 | Bruce Morton

Here is a post by Adam Langley, a transport security person at Google. These were his notes before a talk that he did at HOPE9 last week. HOPE stands for Hackers on planet Earth.

Adam’s talk does not focus on CAs and certificates. His notes deal with HTTPS issues and he really pushes for the use and adoption of HSTS. This information would be good for those people that deploy SSL/HTTPS on their Web servers.

Please take a look.

Updated October 5, 2012: Adam’s presentation has been posted.

Tags: , , , ,
Posted in SSL Deployment | Add Comment | No Comments »

Addressing Mixed Content
Vulnerabilities

Thursday, June 30th, 2011 | Bruce Morton

I fail to understand why website operators continue to deploy sites with Mixed Content. Are the following trust dialogues presented to their users not sufficient incentive to correct the problem? Nevertheless, a recent study showed that 22 percent of sites use Mixed Content.

Mixed Content warning from Microsoft IE8

Mixed Content warning from Mozilla Firefox 4

Internet Explorer (IE) and Firefox present these security dialogues by default. That means if your site has Mixed Content, approximately 65-75 percent of your users are seeing this warning. The problem is the user is trained to just click through the warning and not make a legitimate trust decision.

With IE9, Microsoft is trying to mitigate the user impact of Mixed Content. By default, IE9 will not display unsecured content delivered to an HTTPS page with the exception of unsecured images. For unsecure images, no warning is displayed; however, the lock icon is removed from the address bar. The idea is that only the image itself can be manipulated if it is delivered insecurely, but the image cannot be used to run a maliciously script. In addition, IE9 includes stronger protection against Mixed Content vulnerabilities in HTTPS-delivered frames by providing the Mixed Content warning even if the top frame is HTTP only.

Google Chrome currently does not deliver a Mixed Content warning. Chrome does display subtle indications in the address bar, but no pop-up. With Chrome 14, Google is planning to provide more useable information to the user by adding an info bar when a mixed-scripting vulnerability is detected.

Mixed script warning from Google Chrome 14

Both Microsoft and Google also provide improved tools to help website developers discover the source of Mixed Content warnings.

The lesson for website operators is the browser vendors are taking Mixed Content issues seriously and will continue to provide warnings to users that may impact traffic that visits your site. Best to get ahead of the curve and remove these vulnerabilities.

Tags: , , , , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | 1 Comment »

Is it SSL, TLS or HTTPS?

Thursday, May 12th, 2011 | Bruce Morton

Throughout this blog I appear to use (or misuse) the terms SSL, TLS and HTTPS interchangeably. From time to time I catch myself and say, “Which one should I be using?” Frankly, my default is to use SSL. When I reference an article or site, I do tend to side with the term it prefers. So what’s the difference?

Secure Sockets Layer (SSL) is a cryptographic protocol that enables secure communications over the Internet. SSL was originally developed by Netscape and released as SSL 2.0 in 1995. A much improved SSL 3.0 was released in 1996. Current browsers do not support SSL 2.0.

Transport Layer Security (TLS) is the successor to SSL. TLS 1.0 was defined in RFC 2246 in January 1999. The differences between TLS 1.0 and SSL 3.0 were significant enough that they did not interoperate. TLS 1.0 did allow the ability to downgrade the connection to SSL 3.0. TLS 1.1 (RFC 4346, April 2006) and TLS 1.2 (RFC 5246, August 2008) are the later editions in the TLS family. Current browsers support TLS 1.0 by default and may optionally support TLS 1.1 and 1.2.

Hypertext Transfer Protocol Secure (HTTPS), or “HTTP Secure,” is an application-specific implementation that is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS. HTTPS is used to provide encrypted communication with and secure identification of a Web server.

In addition to HTTPS, SSL/TLS can be used to secure other application-specific protocols such as FTP, SMTP, NNTP and XMPP.

What terminology should we use? Since TLS has succeeded SSL, logic dictates that we should be using the term TLS instead of SSL. However, SSL is by far most common on the Internet, so SSL will continue to be my default acronym of choice when making non-application specific references. From time to time, I will use SSL/TLS. When talking about HTTPS, I may use SSL, SSL/TLS or HTTPS, who knows?

Tags: , ,
Posted in General, Technical | Add Comment | No Comments »

HTTPS Now

Friday, May 6th, 2011 | Bruce Morton

Do you want to make the Internet a safer place? Maybe this is something for you.

Internet activists, Electronic Frontier Foundation (EFF) and Access have teamed to launch HTTPS Now, an international campaign aimed at soliciting consumers to help make web surfing safer. HTTPS Now comprises three initiatives:

  1. Individuals are encouraged to use HTTPS Everywhere, a security tool for Firefox that automatically encrypts the user’s browsing session by changing from HTTP to HTTPS whenever possible,
  2. Individuals are asked to complete the HTTPS Now survey advising whether a site uses HTTPS and how it has been implemented, and
  3. Website operators are encouraged to use selected resources to learn how and why to deploy HTTPS correctly. See “More information & Other Resources” at HTTPS Now.

Proper deployment of HTTPS can limit the impact of malicious tools such as Firesheep which can be used to compromise email or social network accounts.

Tags: , ,
Posted in SSL Deployment, Secure Browsing | Add Comment | No Comments »

HTTPS Performance Tuning

Monday, February 14th, 2011 | Bruce Morton

Following up my last post, “SSL is not computationally expensive anymore,” I noticed Google is still using a 1024-bit RSA certificate for Gmail. I did some digging and confirmed that the performance hit of using a 2048-bit RSA key is about five times that of 1024-bit key. So this could create a 5-10 percent load on CPU and network overhead versus 1-2 percent.

With the industry moving to minimum keys sizes of 2048-bit RSA, your mileage may vary. In order to get the best performance over HTTPS, some performance tuning may be required. Here are some tips from the HTTPWatch blog:

  1. Use Keep-Alive sessions to reduce overhead by reusing TCP connections for multiple HTTP requests.
  2. Avoid mixed-content warnings by ensuring that everything on the page is accessed over HTTPS.
  3. Use persistent caching for static content to reduce load on the website and improve performance when a user revisits your site.
  4. Use an HTTPS-aware sniffer to help you optimize and debug your client-server applications.

Check out the HTTPWatch blog for the details on the above items.

Tags: , , , ,
Posted in SSL Deployment, Technical | Add Comment | No Comments »

« Older Entries