If I got an SSL certificate for my website and use an SSL secured connection (HTTPS), is this safe enough to send my login and password data or should I add some encryption or hashing?

And how safe is SSL against Man In The Middle attacks? Can they grab or even modify the data sent and received over HTTPS?

And what about GET and POST, are both of them encrypted or is just the answer of the server encrypted or even nothing?

I read Wikipedia and a lot of Google results about SSL and HTTPS but I don't really get it. I really hope that you are able to answer my questions in a simple way so I can finally understand how safe SSL and HTTPS really are.


5 Answers 5


Principle of HTTPS operation

HTTP protocol is built on top of TCP. TCP guarantees that the data will be delivered, or it is impossible to deliver (target not reachable, etc.). You open a TCP connection and send HTTP messages through it.

But TCP does not guarantee any level of security. Therefore an intermediate layer named SSL is put between TCP and HTTP and you get the so called HTTPS. This way of working is called tunneling – you dump data into one end of (SSL) tunnel and collect it at the other one. SSL gets HTTP messages, encrypts them, sends them over TCP and decrypts them again at the other end. Encryption protects you from eavesdropping and transparent MITM attack (altering the messages).

But SSL does not only provide encryption, it also provides authentication. Server must have a certificate signed by a well known certification authority (CA) that proves its identity. Without authentication, encryption is useless as MITM attack is still possible. The attacker could trick you into thinking that he is the server you want to connect to. Private chat with the devil is not what you want, you want to verify that the server you are connecting to really is the one you want to connect to. Authentication protects you from MITM.

Weak points

So where are the weak points?

  • Endpoints of secure connection. The transfer could be secure, but what about the server itself? Or the client? They may not.
  • Not using HTTPS. Users can be tricked into not using the scheme in various ways.
  • Untrustworthy CAs. They break the authentication part, allowing for MITM attack.
  • Weak encryption mechanism. Crypto technologies age in two ways: Serious flaws might be found in their design, leading to attacks much more efficient than brute force, or their parameters and processing power increase due to Moore's law might allow for a feasible brute-force attack.
  • Implementation of the scheme. Well, if you specify A and implement B, properties of A may not hold for B.

Direct answers

  • You seem to say that you secured the transfer (using SSL). This is not enough, the security of your server can be compromised – you should not store passwords there in plain text, use their hashed form, with salt added, …

  • SSL encrypts data both when sending and receiving. MITM attacks are possible virtually only when the attacker has certificate signed by an authority the client trusts. Unless the client is tricked into not using HTTPS, nobody can read nor modify the messages being sent.

  • GET and POST are just two methods of making HTTP request. There are several other, too. Method is just a property of HTTP request. All messages are secured, both requests and responses, regardless of HTTP method being used.

  • Is it difficult procedure to get a CA ? or does it assure that the source is valid, because only trusted company get CA ?
    – ransh
    Commented Aug 31, 2017 at 7:38
  • You can create your own CA that only you trust quite easily, e.g. for testing purposes or for internal use, but setting up a CA that is widely trusted (its certificate is pre-installed in OSes and web browsers) is a huge undertaking. When the CA is compromised, all who trust it are too, so very high security of its operation is required. Regulations require audits; see e.g. the US WebTrust. (Not to be confused with web of trust, which is a decentralized alternative to the centralized PKI trust model. CAs are parts or the PKI trust model.)
    – Palec
    Commented Aug 31, 2017 at 8:03
  • Some companies have their own CA installed on work computers, so the firewall can look into all the traffic.
    – Tigerware
    Commented Oct 23, 2018 at 7:13

SSL protects data in transit by encrypting it. It only ensures, to a client, that data will make it from their computer to your server without being intercepted or altered (the encrypted data could be intercepted but has no meaning without decryption). That said, it is the client's responsibility to ensure that SSL is functioning properly before they send any data or trust output from the server. There are attacks that will remove SSL from the connection, but not that will intercept or alter data sent over a secured SSL connection.

SSL does not provide any security once the data is on the server. It is still necessary to use hashing and server side encryption if you want to protect the data at rest from breaches to the server itself.

HTTPS is HTTP sent over an SSL encrypted connection. It covers both GET and POST and any other HTTP actions as the entire HTTP stream occurs unaltered but is passed through an SSL tunnel to the client browser.


SSL only secures the connection between client and server. In theory it does it fairly well (ok, there are some problems - but these are minor compared to all the other problems :) as long as none of the about 150 CA you trust inside your browser gets compromised or works together with some agencies and gives them intermediate CA to do man-in-the-middle attacks.

And, like I said, it secures only the connection between client and server. So any problems in your web application like Cross-Site-Scripting, Cross-Site-Request-Forgery, SQL-Injection, insecure Session-IDs etc will mostly still work, even if the connection is encrypted. Also, the server can be compromised etc.

In summary, SSL is kind of necessary to secure data, but it is not the only thing you need to do to keep data secure.

  • Ah ok, thanks for this answer. :) Uhm you said the connection is encrypted, does this mean GET and POST requests?
    – ReeCube
    Commented Mar 18, 2014 at 11:04
  • 1
    @ReeCube You're correct. HTTP works under the cover of SSL/TLS. Think of SSL as a secure "tunnel" between your browser and the server. Inside that tunnel, HTTP requests can happen. POST, GET, and other kind of requests and their responses.
    – Adi
    Commented Mar 18, 2014 at 11:08
  • 4
    @ReeCube I would like to politely remind you that it can be a very bad idea to handle a production system's security on your own. I highly recommend consulting a security expert.
    – Adi
    Commented Mar 18, 2014 at 11:12

From whom are you trying to secure the communication? If it's the NSA or any other state-level security agency, the answer is no: they have the resources and the technology to successfully implement man-in-the-middle attacks against SSL. If it's large-scale criminal networks, the answer is still no: they can't compromise certificate authorities the way the NSA et al. can, but they can easily compromise machines themselves, and have a look at outgoing data before, and incoming data after, encryption. If you're just hosting a server, though, that's less of a worry for you, since it's vastly more likely that the compromise will happen on the end user's machine and then it's their problem. If it's random packet-sniffers trying to steal and exploit data, then yes - and in spite of the foregoing, it's still enough of a threat that you should use SSL whenever possible.

  • This is not enirely true I think. In the course of Edward Snowdens leaks it became apparent that SSL is safe if implemented correctly and that the NSA is not able to compromise.
    – vanthome
    Commented Mar 19, 2014 at 14:24
  • The NSA can spoof SSL certificates undetectably.
    – Robotman
    Commented Apr 2, 2014 at 11:07
  • 1
    The NSA could theoretically do that if if they can force one of the CAs to cooperate with them (and give them a certificate for a key they generated). Commented Feb 15, 2016 at 18:42

One important detail that the other answers didn't mention is that SSL does not encrypt the URL of the request. Note that under the GET scheme, data is usually encoded as parameters in the URL. This means that if you submit a form with a password field over GET, the password will NOT be encrypted.

  • 5
    I'm pretty sure that is not true. The entire HTTP payload is transmitted through the SSL tunnel, including the headers. See this SO post for details: stackoverflow.com/questions/499591/are-https-urls-encrypted
    – Brandon
    Commented Mar 19, 2014 at 1:26
  • Whoops, looks like I was wrong then! But the DNS lookup to find the IP address of the host is still done in plaintext, I believe (but maybe only the hostname and not the full URL is used for that?).
    – stovetop
    Commented Mar 19, 2014 at 4:48
  • 1
    Yes, DNS lookups are usually insecure (in plaintext) but they contain only the hostname, not the full URL. The only time that actual data might get transmitted in plaintext is if the initial request (to say http://facebook.com) went to plain HTTP, and then the server redirected the user to a HTTPS URL (https://facebook.com). The initial request would be plaintext, but the following one would be fully encrypted, URL and all headers included.
    – Simon East
    Commented Mar 19, 2014 at 6:55

Not the answer you're looking for? Browse other questions tagged .