top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

What is SSL and why is it not enough when it comes to encryption?

0 votes
921 views
What is SSL and why is it not enough when it comes to encryption?
posted Jul 2, 2019 by Siddhi Patel

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

SSL stands for Secure Sockets Layer and, in short, it's the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two systems, preventing criminals from reading and modifying any information transferred, including potential personal details. The two systems can be a server and a client (for example, a shopping website and browser) or server to server (for example, an application with personal identifiable information or with payroll information).

It does this by making sure that any data transferred between users and sites, or between two systems remain impossible to read. It uses encryption algorithms to scramble data in transit, preventing hackers from reading it as it is sent over the connection. This information could be anything sensitive or personal which can include credit card numbers and other financial information, names and addresses.

TLS (Transport Layer Security) is just an updated, more secure, version of SSL. We still refer to our security certificates as SSL because it is a more commonly used term, but when you are buying SSL from Symantec you are actually buying the most up to date TLS certificates with the option of ECC, RSA or DSA encryption.

HTTPS (Hyper Text Transfer Protocol Secure) appears in the URL when a website is secured by an SSL certificate. The details of the certificate, including the issuing authority and the corporate name of the website owner, can be viewed by clicking on the lock symbol on the browser bar.

Why SSL is not sufficient
SSL is great, but it is simply not enough. The interception the data packets flowing between visitor and website is only one way internet criminals gain access to sensitive information.

If SSL has not been properly implemented, some content on a site may NOT covered by the encryption expected. So even though the browser is indicating a secure connection, some of the interactions may not be secure or encrypted at all. There are also potential exploits that can endanger this data exchange. Examples include:

MIME mis-matches
Cross-site Scripting
Clickjacking

All of these are well-known methods used by internet bad-actors to extract information being exchanged between websites and users. But all of these can be effectively defended against using a relatively simple website security best practices.

answer Jul 4, 2019 by Salil Agrawal
Thank you @Salil Agrawal to help me
It is really helpful to me.
Similar Questions
+1 vote

I've been off the list for a bit, getting ducks in a row here and everything.

I noticed a number of posts about SSL & TLS security settings lately and I wanted to point out that maintaining your SSL configurations is an on-going processes.

New exploits are discovered and released quite often, and often the fault lies with a cipher and not necessarily an overall SSL/TLS protocol.

So using a cipher list like "all except RC4" is probably not sufficient anymore. And what is secure may depend completely on the SSL/TLS software you use, be it OpenSSL or Java's built in SSL libraries.

For example, with OpenSSL, you should be using 1.0.1t or higher, and even then only TLS1.2 with a handful of ciphers. I'm not sure what the recommended options for java's libraries are at the moment. A really good, free tool is Qualys' SSL Labs server test tool located at: https://www.ssllabs.com/ssltest/ Run that against your implementation and follow its recommendations.

Of course, at the end of the day, it will be up to you and your firm to decide what risks you are willing to take with your SSL communications and whether or not you need to support insecure browsers, i.e. browsers that cannot negotiate up to the most secure protocol and ciphers.

+1 vote

I have 3 virtual hosts that for all I can see are configured identically other the the obviously needed differences. The same is true of the 3 crt files.

 ServerName public.mydomain.com
 DocumentRoot /var/www/html
 SSLEngine on
 SSLCertificateFile /etc/httpd/SSL/public.crt
 SSLCertificateKeyFile /etc/postfix/SSL/server.key

 ServerName distrib.mydomain.com
 DocumentRoot /var/www/html/distrib
 SSLEngine on
 SSLCertificateFile /etc/httpd/SSL/distrib.crt
 SSLCertificateKeyFile /etc/postfix/SSL/server.key

 ServerName mail.mydomain.com
 DocumentRoot /usr/local/squirrelmail/www
 SSLEngine on
 SSLCertificateFile /etc/httpd/SSL/mail.crt
 SSLCertificateKeyFile /etc/postfix/SSL/server.key

The problem is that 2 of them work perfectly and the lock shows up in the browser. With the third (public), I get a gray globe indicating partial encryption which does not prevent eavesdropping. I have no clue
how to debug this or even where to look. Can someone point me in the right direction?

+1 vote

I have an idea how to setup Apache for doing load balancer based on mod_proxy and mod_balance modules. But in my case the backend server requires ssl client certificate authentication and therefore the Apache Server cannot terminate the ssl connection.

I do no need http session cookie stickyness. The application is stateless. Can I somehow configure Apache as a transparent balancer?

Or I should use even another software - squid, iptables? The backend application is a web service running on Tomcat.

0 votes

Has anyone happened to stumble onto this issue, please:

Our Ajax works perfectly as long as its non-secure. However, when switching to SSL we sometimes see 408 errors (incomplete request). This only happens on ajax, and inconsistently (similar requests might succeed on one moment, but fail on the other).

Please note:
1. Our client is Chrome browser, using JQuery for ajax
2. Server is Tomcat 7
3. Network is fast and stable, and the ajax requests are small
4. Problem occurs for both our connectors: APR and Http (both with SSL enabled)
5. Our x509 certificate is valid (otherwise it would have failed on *all* ajax ssl requests, not to mention the non-ajax ssl)

...