Posted SHA1 certificate shown as insecure or with mix content warning on Google Chrome 39 on Blog
As of late 2014, SHA1 certificates and it's SHA1 trust chain (not including the Root CA) will be considered insecure by Google Chrome.
A three step process will increase the severity of the warning:
To resolve this issue SHA2 certificates must be installed.
What about the Cross Root Chaining? For example:
As per Ryan from Google:
"On all of our platforms, it will prefer (1) if ca1 is trusted. It would only go to (2) if ca1 is not trusted.
On the platforms where this is the case, the peer supplying ca1-ca2(sha256) as part of the handshake ensures that (3) is preferred, if ca2 is trusted."
Mar 07 2018, 9:10 AM
Posted Types of SSL certificates – choose the right one on Blog
From the server administrators of highly technological organizations, to product managers of financial institutions, down to the one man startup companies that just want to secure their shopping cart, at one stage or another, the same question pops-up: “They all do the same thing, what should we get?”
Fundamentally all SSL certificates do the same thing, encrypt information during SSL/TLS negotiations. Correctly installed and configured, both https:// and the padlock will show.
However picture this:
You want to buy smart phone online. You see three sellers offering the phone at different prices:
US$250 – Zero star rating – no comments
US$375 – Three star rating - with 50% of comments such as “it arrived late”, “It was scratched” and other 50% of the comments, “ok service” and “arrived on time”.
US$400 – Five star rating – with only good comments: “excellent service” and “fast and reliable”.
Which seller will be most likely to deliver the goods to you on time? The one offering $400?
Why? The comments from previous buyers formed a conscious or sub-conscious decision in your mind. The decision is based on “Trust”. They have been authenticated by real people.
Anyone that purchased from the first two sellers most likely would base their decision on both price and luck (“Maybe I would not be unlucky”).
Here’s another scenario: A hooded man walks out from a dark alley and offer you a brand new IPhone 6, still in its box for US $50.
Do you feel lucky today?
Owning a Certificate
Before requesting a certificate, most security administrators would have done their analysis homework. Is it for internal or public use? What is the user base and their method of use? What operating system and server software are involved? What systems will be impacted? What are the security policy requirements?
Beyond the technical specifications often a key question is neglected, the question of User Trust. Owning an SSL certificate it is not only about the functionality, or the key size, but rather as the Thawte motto goes, “It’s a trust thing”.
Today there are three types of certificates that offer 3 levels of user trust for SSL/TLS negotiations: Domain Validated certificates (DV), Organization Validated certificate (OV) and Extended Validation certificates (EV).
Domain Validated Certificate
Domain Validated certificates are certificates that are checked against domain registry. There is no identifying organizational information for these certificates and thus should never be used for commercial purposes. It is the cheapest type of certificate to get, but this is a high risk certificate use on a public website. It is comparable to the “hooded man” or the zero star rating sellers. Visitors to a website with DV certificates cannot validate, via the certificate, if the business on the site is legitimate and thus often DO NOT trust this type of certificate. It is recommended using these types of certificates where security is not a concern, such as protected internal systems.
This is an example of a DV certificate via Internet Explorer:
Details of the certificate subject: CN = www.domain.com
Organization Validated Certificate
Organizational certificates are Trusted. Organizations are strictly authenticated by real agents against business registry databases hosted by governments. Documents may exchange and personnel may be contacted during validation to prove the right of use. OV certificates therefore contain legitimate business information. This is the standard type of certificate required on a commercial or public facing website. OV certificates conform to the X.509 RFC standards and thus contain all the necessary information to validate the organization.
Details of the certificate via Firefox:
Details of the certificate: CN = www.domain.com, O = Company Name, OU = Information Technology, L = San Diego, S = California, C = US
Extended Validation Certificate
Nothing provides more trust and security than Symantec Extended Validation Certificates. It is used by most of the world’s leading organizations. They have found that switching from OV to EV certificates increases online transactions and improve customer confidence. It is no longer a luxury but a necessity.
“An important motivation for using digital certificates with SSL was to add trust to online transactions by requiring website operators to undergo vetting with a Certificate Authority (CA) in order to get an SSL certificate. However, commercial pressures have led some CAs to introduce ‘domain validation only’ SSL certificates for which minimal verification is performed of the details in the certificate.
Most browsers' user interfaces did not clearly differentiate between low-validation certificates and those that have undergone more rigorous vetting. Since any successful SSL connection causes the padlock icon to appear, users are not likely to be aware of whether the website owner has been validated or not. As a result, fraudsters (including phishing websites) have started to use SSL to add perceived credibility to their websites.” – Wikipedia.
EV certificates reinstate the trust users have for a secured web site. The criteria for issuing EV certificates are defined by the Guidelines for Extended Validation and provide a vetting process that is much stricter than that for OV certificates. Apart from improving trust and confidence via the strictest authentication process, EV certificates triggers a visible Green Bar on modern browsers to distinguish the secured site apart from others. The combination of Symantec’s world trusted strict validation procedures, the Symantec/Norton Seal and the Green Bar provides the highest degree of trust amongst consumers. It is extremely difficult to impersonate or phish an EV enabled site as even if web content can be duplicated, the Green Bar cannot be triggered without a trusted EV certificate.
Browsers that support EV Green Bar:
Google Chrome, Internet Explorer 7.0+, Firefox 3+, Safari 3.2+, Opera 9.5+
Immediately when accessing a secured EV enabled site with one of the above browsers, the following can be seen:
(EV Green Bar cannot not be triggered by DV or OV certificates)
Detailed certificate information:
Visitors viewing details of the certificate will find more information about the organization than a DV or OV certificate:
Symantec Certificate policy required for the Green Bar:
EV is good. It does work. Have a look at some of the success stories clients have at Symantec EV Success. The discoveries of vulnerabilities and increase in organized cyber-attacks in the recent years have made consumers more and more aware of security and SSL. More and more consumers look for the Green Bar and the Symantec Seal when doing online transactions. Extended Validation goes beyond security. It has become the baseline for any reputable site that care about security, brand and their clients.
EV makes a difference. It has proven advantages over sites that do not have EV. Not all organizations are feasible to receive an EV certificate. However sites that switched from standard OV to EV have experienced 5 – 28% increases in web traffic and sales volumes. Commercial web sites cannot settle for anything less than EV status if they wish to stay competitive.
What certificate to choose? Go Green. Green is good.
Mar 07 2018, 9:10 AM
Posted Perfect Forward Secrecy - Protecting the gateway to your world on Blog
Remember the movie "The Truman Show", where Jim Carrey played the main character of a TV show that chronicled the life of a man who was initially unaware that he was living in a constructed reality television show, broadcast around the clock to billions of people around the globe. Imagine that your organisation is chronicled the same way. Every online transaction, secured or not.
That's what Heartbleed can do. Fortunately most systems using OpenSSL libraries have been patched (hopefully) to counter this. What if there is another way that this can be done. That this could be happening right now, on a daily basis and that this is not a vulnerability, but is actually how most clients connect to organisations during SSL/TLS negotitaions for the past decade?
Fristly have a look at how SSL/TLS handshake works.
Consider this scenario:
A script kiddie downloads Wireshark and uses it to track network activities within your organisation. Entire transations are recorded, including SSL sessions. Several years later, after gaining much experience, he can now gain access to the servers and the expired Private Key pairs that were once used to encrypt these sessions. These sessions were encrypted with RSA key exchange. He emails the CSO, "I know what you did last summer".
OK. A bit too dramatic and over the top, but perfectly possible. This is the flaw (not vulnerability) when using RSA Key Exchange in SSL/TLS negotiations without proper Key Management. As each session is related to the RSA private key used, recorded sessions can be decrypted later.
An alternative to the RSA key exchange is to use another algorithm, Diffie-Hellman, which creates sessions that are not associated with the private key. Even if the session information is recorded there is no easy way to decipher the computations. With proper Diffie-Hellman implementation, encrypted information cannot be deciphered in the future. This is called Forward Secrecy.
To see how Perfect Forward Secrecy can be be achieved, ready your coffee, get your thinking cap on and start reading the document attached.
Mar 07 2018, 9:10 AM
Posted How does SSL work? What is an SSL handshake? on Blog
A special request was made today: "How does SSL work? What is an SSL handshake?"
Here are some quick info.
SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.
For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.
For a list of the server softwares Symantec has, have a look at: Symantec CSR Generation
Note that although certifcates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.
Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol. On browser applications it is usually https://www.yourwebsite.com.
Remember to use your secured website address. Above is just a sample address.
That will start the SSL/TLS negotiation:
Keys and Secrets during RSA SSL negotiation
The following is a standard SSL handshake when RSA key exchange algorithm is used:
Tools such as OpenSSL can be used check the SSL/TLS negotiations:
OpenSSL s_client -connect www.symantec.com:443 -state -ssl3
SSL_connect:SSLv3 read server certificate A
There it is. SSL and SSL Negotiation summarized. Mission complete.
Now! Do Not Forget To Back Up Your Private Key and Certificate in a Secure place in case of system issues!
Mar 07 2018, 9:10 AM
Posted Think you're safe? Think again - SSL Attack Survey on Blog
Look! I have a lock, I see https://, I even see the Green Bar, I believe I have protected my server and the clients connecting to our services from attackers now. I can't start increasing security and block clients to my site by disabling SSLv3, MD5 or RC4. I'll be losing customers and profit! I can accept a weaker security as long as user traffic and profit are not affected.
Performance vs Security is a constant struggle between security experts and management. When it comes to SSL it is no different. Do we allow as many clients to access our site as possible, or do we block all the weak connectivities. There has been numerous studies on this, so I won't go into it here. As a SSL security expert, allow me to take sides this time. Allow me to provide some more gear for us to convince our management why SSL security is more important and how we can migitate the risks without affecting performance or traffic too much.
Last year September a comprehensive survey was done by iSECPartners,Inc on the various vulnerabilities with the SSL/TLS technology.
Have a look: Attack on SSL
Mar 07 2018, 9:10 AM
Posted SSL Ciphers - Beyond Private key and Certificate on Blog
Today SSL is an integral part of online businesses and any secured communication. It is however not an area that many system administrators or security experts are comfortable with. For most administrators the correct installation of the private key and its corresponding certificate is sufficient. As long as the green bar, the padlock, or https:// can be seen during the SSL/TLS negotiation, both the administrators and their clients trust that the connectivity is secure.
However many security flaws and vulnerabilities have been discovered in the recent years. From the server side there is the infamous Heartbleed bug or CCS injection - CVE-2014-0224, side-channel attacks such as Beast, Lucky 13, Crime or BREACH, and others (SSL Attack Survey). It is not sufficient to just have a correct installation of the private key and certificate pair on the server. Beside patching up server libraries and client applications, additional control to SSL/TLS negotiations need to be applied. One of those control mechanisms is selecting the right cipher suite.
The strength of an SSL/TLS negotiation depends not only the size of the private key or certificate. As of 2014, the recommended minimium key pair size is 2048 bit, however this does not guarantee maximum encryption sessions. During SSL/TLS handshakes, the agreement of what cipher suite to use determines if the negotiation will be using SSL or TLS protocols. It also determines the key exchange and encryption algorithms. If the agreed encryption level between the client and the server is low, the SSL/TLS session will still be vulnerable. For a system to be truly secure, strong cipher suites are required.
To address this issue, a project was initiated. The result, "SSL/ TLS Cipher Suite Analysis and strong Cipher Enablement" is included in this blog.
The purpose of this research is to provide an implementation process to set up a strongly secured SSL/TLS system by viewing the available cipher suites present in a system, recognizing the strength and weakness of the different ciphers and choosing the most applicable cipher suite.
Note: The configuration examples given in this document do not represent the complete or best set of strong ciphers to use. Depending on the various security policies and business requirements, the examples given in the document may not apply .
Mar 07 2018, 9:10 AM