SSL Implementation Security FAQ


SSL Implementation Security FAQ is about implementing SSL in web and desktop applications. This FAQ doesn’t cover issues directly related with SSL/TLS. Only covers issues related with implementing SSL in applications.

Most of these are common mistakes during the implementation of SSL in the applications. These recommendations are especially critical for e-banking, e-commerce and similar websites.

Is it secure switch back to HTTP after login over HTTPS?

No it is not. All communication during the authentication and after authentication should be over SSL.

There are several reasons:

Previously this mistake has been done by Google Gmail.

Can I put my Login form to HTTP and target my form to HTTPS?

No, that’s just a terrible idea and almost pointless. This is common mistake has been done by several major websites such as Godaddy.

What’s the best way to secure an SSL website?

Disable HTTP access to the domain, don’t even redirect or link it to SSL. Just inform the users this website is not accessible over HTTP and they have to access it over SSL.

This is the best practice against MITM and phising attacks. This way your users will be educated that application never accessible over HTTP and when they come across to a phising or MITM attack they will know something is wrong.

One of the best ways to protect your application against MITM attacks and phising attacks is educating your users.

How cookies and SSL play together?

You should always mark your cookies as secure. Otherwise you’ve got a big security risk. Marking cookies as secure will prevent browsers to sending cookies over non SSL connections.

An attacker can force someone to do a connection over HTTP to steal their cookies and generally cookies carries of session critical information such as Session ID. Thus preventing this attack and marking cookies as secure is quite important.

How to Implement SSL in non Web Applications?

Your application should not trust non-valid certificates, if you allow this MITM attacks will be successful against your application. Depending application features and requirements this can lead Remote Code Execution easily.

I’ve seen this problem in many of bespoke applications. Generally developers leave support for non-valid certificates for testing purposes and deploy it like that. By default many of the underlying API won’t accept connections to non-validated certificated applications, it’s a good idea to keep it like that.

Should I implement SSL support to non Web Applications?

Yes you should, depending on the functionality it’s quite possible to do remote code execution because of non SSL connections.

Two following actions are highly vulnerable to this problem:

· Auto-update functionality of the application,

· Rendering a remote HTML in local-zone with Web Browser Control or in a similar control. Don’t forget every application is vulnerable to Cross-site Scripting if they are not over SSL!

Firefox was vulnerable to this, another similar one identified in a Vista Gadget.

Can I put an order form designed for offline usage to print over non SSL?

You might think putting a simple order form without a submit but designed to print and post over non-SSL could be secure, but guess what it’s not secure at all!

An attacker can inject a piece of JavaScript to this request, can log every single keystroke and send them to attacker’s website automatically. Thus you shouldn’t put an order form or any similar form which requires private information such Credit Card details, address, phone numbers etc.

In a similar way putting an offline order form such as PDF file to over non-SSL URL is another bad practice since attack can send this PDF file on the fly and modify post address or similar information to get benefit out of it.

This is common problem with banking websites where they provide these kind of forms over non-SSL connections.

Should I support weak ciphers?

No you should not. Main reason behind of supporting these ciphers is supporting old browsers but supporting old browsers is a terrible idea since the internet is full client-side exploits for old browser.

Which means a user with an old browser is potentially infected by a malware already. Remove support for weak ciphers from your web server.

Paypal announced that they don’t support old browsers any more.

Can I support weak ciphers in web server level but restrict access to the application when someone uses weak ciphers?

No you should not do that. This is a process where web server supports connection with weak ciphers but application informs that user can not continue unless they change their browser and come establish a new connection with a stronger cipher.

These ciphers are called as “Weak Ciphers” because they feasible crackable with a decent computing power. Basically a data transmitted over weak ciphers are highly vulnerable to cracking. Therefore an attack can sniff this data then crack and view transmitted data later.

This is dangerous because depending on the application, it might transfer cookies in these weak cipher used connections, (obviously including cookies those marked as secure). Even though application will inform to user that they can not keep using application this first request will send HTTP request over non-SSL connection and an attacker can see this request.

An attacker can be for victim to do this first request over another website in many different ways such as iframe. It’s enough for an attacker to modify one HTTP response on the fly to accomplish this.

ActiveX Security and SSL

If your application requires a custom ActiveX and if your ActiveX allows you to do something more privileged than normal a browser such as reading local files, executing certain OS commands then you should limit your ActiveX execution to only your domain.

If you limit your ActiveX only for your domain but not only for your domain and HTTPS access then an attacker can do MITM attack and can call this ActiveX over your domain and can use all functionality of the ActiveX. Obviously this can lead vulnerabilities such as arbitrary file reading from local file system, code execution or information leakage.

You should restrict your custom ActiveX applications to your own domain and SSL. This will stop this attack.

Download, MD5 Signatures and SSL

There of lots websites providing hash signatures of files, this is good for especially confirming the integrity of file against file corruption and similar issues. But if you put your files over HTTP then you should know that those hash based signatures are meaningless from security point of view.

An attacker can change file as well as the hash signatures on the fly.

Trusted Zone Required Applications and SSL

Some web applications require adding them to users Internet Explorer’s Trusted Zone list. This allows them to do more privileged actions such as installing ActiveX controls or writing local file system.

This is bad practice anyway and you shouldn’t do this unless you have to. If you have to this you should inform users that they should add your website to the trusted list with HTTPS not HTTP.

Any user with an HTTP entry in their Internet Explorer Trusted Sites list is vulnerable to remote code execution attacks. It should be noted that since IE 7 Trusted Zone a lot more secure than IE 6 and may not allows remote code execution by default.

3rd Party Browser Add-ins and SSL

HTTP/1.1 RFC 2616 clearly states that clients should not include HTTP Referrers to connections over SSL:

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.

Reasons are:

This means when a user browses a web application over HTTPS, this add-on will send current SSL URL to their server over HTTP. Therefore attackers can see this URL and this is clear breach of URL privacy in SSL.

Why mixed content (HTTP and HTTPS) is dangerous in one page?

Browsers pops up a warning box when a page calls HTTP resources over an HTTPS URL. This generally happens if you try to include external JavaScript or Flash resources from an HTTP URL. This is bad because an attacker can do MITM to HTTP content and execute JavaScript in the same domain. This is very simple especially if this warning causes because of an external JavaScript resource.

Should I trust websites which pops-up some SSL warning?

Depends on the details on the warning, but simply No you should not. This generally indicates one of the following problems;

All of these are not good and you shouldn’t trust them.

Is SSL just for authentication required applications?

No, if you consider the transmitted data between you and the visitors as private you should use SSL.

Most of the following component should always be over SSL:

Search and results pages maybe looks like overkill to you but imagine you open all of your google searches to public. I bet you don’t want to know people about your deep obsessions, health status, your applications error messages, your home address (google maps), your phone number etc.

Is SSL only about Encryption?

No, it’s also about identification. You can use SSL to prove who you are by getting certificate from a trusted CA by common browsers. Therefore your visitors can check your company name and details by looking into the details of your certificate.

Even though this is not bullet proof solution because of social engineering someone else can come with similar domain name and valid certificate and can carry out a phising or similar attack, even though this is another layer to protect your application against phising or similar attacks.

Also you can use SSL to identify a client to the server.

Should I disable HTTP access?

Yes you should, this is the best practice you can do in SSL usage. Disable port 80/HTTP access to your web server. It helps to prevent phising attacks, will educate users to stick with SSL all the time and will protect you against several wrong SSL implementations pitfalls.

Recent Blog Posts

See all of the blog posts