Other issues in this category (26)
We prefer an overt enemy to a faux friend.
Users are in danger when information leaks from a website’s database. However, the FAQs on many sites offer safety assurances: go ahead and use our resources; there’s nothing to fear.
As an argument in their favor, they usually cite the use of Secure Sockets Layer (SSL).
Your data is completely safe. This website uses the cryptographic protocol SSL and 128-bit connection security, which makes it impossible for cybercriminals to access your data. Don't worry about a thing!
SSL is not a universal remedy!
Of course, the data you transmit from your browser (i.e., from your computer) to the website’s server is safe.
Moreover, the security of SSL is a myth, and this myth is dangerous. Encrypting a channel offers no protection whatsoever in the event the certificate has been substituted on the provider level at the moment traffic is being transferred or in the event it is intercepted at the computer level (also achieved via certificate substitution).
A valid SSL certificate issued for an attacked domain lets hackers carry out an attack covertly using the MITM (Man-In-The-Middle) method. For this method to work, an attacker-controlled host that is actively intercepting traffic must be located between the targeted user and the server. This host presents itself as a legitimate server by submitting the same valid certificate.
The interception of HTTPS connections can be automated—special proxy hosts (SSL proxy) exist that can intercept traffic on-the-fly, including while generating the needed certificates. A certificate and a secret key must be downloaded to this type of proxy to enable the signing of other certificates (e.g., the so-called partner intermediate certificate issued for this purpose suffices).
MITM won’t work for HTTPS if some additional measures exist: for example, the establishment of a TLS (Transport Layer Security) connection requires mutual authentication, and the user’s secret key (or partner keys that vouch for the user’s key) is made unavailable to the intercepting host; or the user’s browser maintains a register of servers whose public key thumbprints are trusted; or the user applies additional sources of information about the authorized keys and certificates that are not available for substitution on the intercepting host (such sources include DNS or other databases).
Most services use so-called SSL termination: i.e., encrypted user HTTPS traffic only travels to an edge proxy server where it is safely translated into HTTP; from there it travels through a service’s internal (in a logical rather than a technical sense) networks in plain text. This is standard practice since total HTTPS, with a growing number of customers, quickly morphs into a very heavy, poorly scalable technology. If a traffic inspection system is located inside service networks, beyond an edge SSL proxy, no HTTPS interferes with it. The internal traffic of distributed services can easily travel in plain text between hosts and data centers along communication channels leased from major providers. While such traffic can be listened to, the user sees what appears to be an HTTPS connection.
And, most important: if your computer is compromised by a malicious program that has access to the browser, HTTPS also becomes useless since data can be intercepted before it reaches an encrypted channel. The same is true on the server side.
On the other hand, browser warnings that a connection is unprotected don’t always mean that your system is endangered.
We’re already long accustomed to Microsoft products having errors; however, it turns out that such mistakes can be encountered beyond their borders. Take, for example, Microsoft’s website—it’s very official-looking, extremely popular, and in high demand. Let’s open it in a browser. Type any query in the search field to request a resource via the HTTPS protocol. But, wait a second...what’s this?
The certificate used by the website was generated for third-level domains. That’s why the browser is a bit surprised at first, but then it gets scared, and finally it advises, “Leave this website immediately!” Yikes, let’s get out of here!
There is no objective necessity to use SSL if you were not going to transmit any information! And for attackers who distribute viruses from a server, an encrypted channel is a pleasant gift. After all, if an anti-virus cannot scan encrypted traffic, a malicious file will overcome all defensive layers and penetrate the system.
Dr.Web SpIDer Mail and Dr.Web SpIDer Gate can scan encrypted traffic.
Sometimes website administrations boast about performing daily automated web scans.
Every day our website is scanned by a web scanner to detect malware and known vulnerabilities. We’ve left criminals no chance of getting in, but, should a miracle happen, we'll find out about it first and take the necessary measures.
In turn, malware scanners verifying a website directly can find all the known threats on it. But, if the server hosting that website is not scanned, security is illusory because the number of Trojans targeting Linux increases every day (this operating system is used most often to create websites). And, if known vulnerabilities can be exploited in automatic mode, it’s highly likely the website would be hacked.
Tools work in skilled hands!#traffic_scan #encryption #security #website #Linux
If you are a user:
- Don’t trust websites when they assure you that your data is secure—numerous leaks of personal data have already shown that websites, just like user PCs, are also vulnerable to successful attacks. Ask whether your favorite service has passed a security audit and what anti-virus is protecting its server.
- Don’t panic when you see warnings advising you to immediately stop using a service; try to figure out what happened on your own or with the help of a professional.
- Remember: there’s always a chance that the data you transmit via the Internet will become available to third parties.
If you are a webmaster: only a resident anti-virus can find a Trojan on your server, especially if it is running Linux!