Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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.

share|improve this question

closed as too broad by Adnan, Xander, Noordung, Luc, GdD Mar 19 at 15:21

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

    
have you ever heard about sslstrip or BREACH? –  yzT Mar 18 at 10:36
    
Yes I heard about sslstrip but I'm not sure if I understood well, can you really sniff plaintext with sslstrip? –  ReeCube Mar 18 at 10:41
4  
This question is extremely broad. One can write pages and pages to cover only half of your question. The mere mention of "should I add some encryption or hashing?" says that this needs a dive into the basics in order to give you a satisfactory answer. I'll have to apologize and tell you to go over this site and find some questions/answers that can give you the start of the rope, and then you'll go on your own in your journey of learning. –  Adnan Mar 18 at 11:04
9  
@yzT Neither SSLStrip nor BREACH attack the SSL/TLS protocol itself. Instead of being condescending, why not try and point the OP in the right direction? –  Adnan Mar 18 at 11:06
1  
Freaky! Just clicked onto this article from the "Hot Network Questions" list and noticed it had 1337 views. img833.imageshack.us/img833/932/pbpe.png –  Simon Mar 19 at 7:00

5 Answers 5

up vote 8 down vote accepted

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. This is generally not an issue, IMO.
  • 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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
Ah ok, thanks for this answer. :) Uhm you said the connection is encrypted, does this mean GET and POST requests? –  ReeCube Mar 18 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. –  Adnan Mar 18 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. –  Adnan Mar 18 at 11:12

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.

share|improve this answer
2  
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 Mar 19 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?). –  boyers Mar 19 at 4:48
    
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 Mar 19 at 6:55

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.

share|improve this answer
    
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 Mar 19 at 14:24
    
The NSA can spoof SSL certificates undetectably. –  Robotman Apr 2 at 11:07

Not the answer you're looking for? Browse other questions tagged or ask your own question.