Answer

The switch to HTTPS: Understanding the benefits and limitations

Following the EFF's recent missive on HTTPS protocol security and the numerous ways in which persistent attackers can work around it to compromise website traffic and data, we're developing a list of ways in which we can go above and beyond standard HTTPS encryption to guard against persistent attacks. What are the most effective tactics we should consider?

    Requires Free Membership to View

Ask a question

SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email: editor@searchsecurity.com.

The Electronic Frontier Foundation (EFF), a donor-funded nonprofit organization, has long highlighted the need for websites to use HTTPS correctly and the necessity of a better solution to the certificate authority (CA) infrastructure. The EFF’s article “How to Deploy HTTPS Correctly” covers several areas of server configuration that site administrators often fail to implement.

The EFF recommends making a full switch to HTTPS, meaning all content on the page must be fetched via HTTPS. Sites often only have partial HTTPS support, usually on the login page where the bulk of the page is fetched via HTTPS, but some of the media elements, style sheets and JavaScript in the page are fetched via HTTP. Although the main page load is protected against active and passive network attack in this situation, none of the other resources are protected, which can leave the user exposed; these non-HTTPS resources cannot be verified as coming from a trusted source. Google is in the process of moving all of its services to HTTPS, which has shown that SSL/TLS is not the CPU hog that many believe. Expect HTTPS to replace HTTP in the next few years in a manner similar to how SSH replaced Telnet.

Transitioning a site to HTTPS is not overly difficult. All HTTP requests with HTTP 301 or 302 responses can be redirected to the equivalent HTTPS resource. Also, Google and Mozilla browsers support the HTTP Strict Transport Security (HSTS) protocol extension that instructs browsers to expect the site to use HTTPS. If a site uses HTTPS, you should also set the scope and secure attributes on any cookie to prevent it from being sent to a non-HTTPS page.

An organization should also implement a content security policy, which requires configuring its Web server to return the X-Content-Security-Policy HTTP header to specify its policy. This is a string containing policy directives to indicate the class of content that is to be restricted by the browser and the range of permitted behavior for that content class. Typically, this is a location, such as a network host, which is permitted to serve content of a particular type. For example, to allow content from a trusted domain and all of its subdomains, the header would look similar to this:

X-Content-Security-Policy: default-src 'self' *.trusteddomain.com

Although the content security policy specification is only a public working draft, it is likely to become a W3C recommendation.

The aforementioned security measures reduce the chances of a site, and those who visit it, from being compromised. However, HTTPS cannot completely prevent persistent attacks, such as those that reside on the site undetected and affect everyone who visits the site. For example, a cross-site scripting (XSS) attack that involves posting malicious code via a comment form on a website and attacks anyone that views the comment, is a persistent attack.

To combat this type of attack, an organization should ensure that all non-static data is validated before it is processed by any Web server application or script. For example, if the code expects an input to be an integer, this requires testing to ensure it is an integer. To do this effectively, an organization needs to declare and use the same HTML encoding throughout its site and scripts. This prevents attackers from slipping through filters by encoding characters using a different character set. There are many ways to break HTTPS, but it is still the best method of providing authentication and encryption between a server and a client. So, make sure the organization has a valid SSL certificate for its website with a minimum key length of 1024 bits.

This was first published in April 2012

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: