I am creating a Node.js server with a secure connection based on an answer from SO.
Code from the answer,
var https = require('https');
From what i understand, there are two parts to secure connection.
SSL handshake which does a certificate verification and symmetric key exchange.
Encrypting the traffic with the symmetric key.
Does https perform only SSL handshake? Does it take care of decrypting the request and encrypting the response? does it use a symmetric key algorithm? does it use AES? If it does not use symmetric key encryption, How can i do that?
Is the traffic flowing encrypted?
P.S: I have left a comment under the answer i quoted. Hope it is alright to derive questions from an answer on SO.
From what i understand, there are two parts to secure connection.
SSL handshake which does a certificate verification and symmetric key exchange.
Certificate verification and symmetric key negotiation.
Encrypting the traffic with the symmetric key.
Correct.
Does https perform only SSL handshake?
HTTPS doesn't do any of it. HTTPS is just HTTP over TLS. TLS does the handshake and the encrypting. The only additional thing HTTPS does is hostname verification.
Does it take care of decrypting the request and encrypting the response?
Yes.
does it use a symmetric key algorithm?
Yes. You already said that above yourself.
does it use AES?
It uses any of a large number of ciphers by agreement between the peers.
If it does not use symmetric key encryption, How can i do that?
It does, and you don't.
Is the traffic flowing encrypted?
For the fourth time, yes.
Related
QUESTION: The initial request/response HTTPS communication between client and server are not encrypted, except for the CA certificate in the response?
If so, what prevents a hacker from seeing the initial client request to the server, and intercept the response from the server,
containing its CA certificate, decrypting the certificate with the CA's public key, get the server's public key in the certificate,
and use it to encrypt its own symmetric key and send to the server, thereby bypassing the client, and establishing a bogus dialog between hacker and server?
This question has already been answered here.
TL;DR
What you are defining is a Man-In-The-Middle attack on SSL, and this can happen only if one of SSL preconditions is broken.
I have a question regarding SSL verification within the requests library for Python, but I believe it to me more general than that.
I am currently ignoring certificate verification because the third party API I need to connect to is using a self-signed certificate.
What are the implications for turning SSL verification off in requests? And what are the implications for not verifying SSL certificates in the real-world. Can I gaurantee the data transported is secure/encrypted?
This is a security sin, as anyone could spoof this certificate and intercept your traffic. You should just add the self-signed certificate to the trusted certificate chain of the machine which is using the API.
How you do that depends on the operating system and specific setup, but a quick google will guide you to the right solution.
Can I gaurantee the data transported is secure/encrypted?
The data is encrypted (this is TLS confidentiality guarantee) but since you did not authenticate the remote part (if you disable certificate validation or bypass all errors) you could be as well sending the encrypted content to anyone, including an attacker, which of course on his side will read it in plain, as the TLS handshake succeeded if you do not validate the remote party.
TLS provides multiple features, two major ones being authentication and confidentiality. They are orthogonal (you can have one without the other) but it may not be so useful to not have all of them.
Contrary to natural thinking, authentication is more important than confidentiality because if you have no insurance about who is the remote party, what do you gain by sending it encrypted? Nothing.
I want to apply web service security according to OWASP Web Service Security. Thereby I stumbled over the two points:
Message Integrity
Message Confidentiality
So far there is just a RESTful service which can be directly accessed by a client. For each request the client needs to authenticate by the server. All communication is secured via TLS. I'm now unsure about Message Integrity since I don't understand the sentence:
When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the
receiver's public key is public. For the same reason, encryption does
not ensure the identity of the sender.
Is it also required that the data was signed by the client in order that message integrity is ensured? TLS is only point-to-point, what is about proxies?
Concerning Message Confidentiality, I understood it as follows.
Use TLS to ensure message confidentiality over the wire.
Use a symmetric encryption to encrypt the transmitted data.
The encrypted data get stored in data base.
Did I understand that right?
From the TLS specification:
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. [...]
The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES [DES], RC4 [SCH] etc.). [...]
The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in
this mode while another protocol is using the Record Protocol as a
transport for negotiating security parameters.
So, yes, TLS will provide you with integrity and confidentiality of the message during its transport, provided that it was used correctly.
In particular, the client needs to verify the certificate to ensure it is communicating with the right server (verifying that the certificate is genuine and issued by a trusted party, and issued to the host name it intended to contact).
Use TLS to ensure message confidentiality over the wire.
Use a symmetric encryption to encrypt the transmitted data.
TLS will provide confidentiality via encryption. (You need to use an appropriate cipher suite, in particular not a anonymous cipher suite or a cipher suite will null encryption, but that's always the case by default.)
The encrypted data get stored in data base.
If you want to encrypt the data in your database, that's a different problem. TLS only provides you with integrity and confidentiality during transport. Once it's handled by your web application, it's deciphered.
TLS is only point-to-point, what is about proxies?
HTTP proxies only relay the TLS traffic as-is, without looking into it or altering it. (Some proxy servers can intercept the traffic, but the certificate verification would fail, unless you forget to check the certificate.)
Does TLS ensure message integrity and confidentiality of data transmission
Yes.
in a RESTful Java enterprise
Irrelevant. Answer is still yes.
When using public key cryptography, encryption does guarantee confidentiality but it does not guarantee integrity since the receiver's public key is public. For the same reason, encryption does not ensure the identity of the sender.
Irrelevant. TLS isn't public-key cryptography. I really fail to see the point of these remarks in this context, but they're not correct. No form of encryption alone guarantees either integrity or identity: you need additional measures for that; and the key being public is irrelevant to that as well.
Is it also required that the data was signed by the client in order that message integrity is ensured?
No. A secure HMAC will do as well, and TLS uses one of those. TLS does use digital signatures during the authentication phase.
TLS is only point-to-point, what is about proxies?
Proxies are either trusted TLS endpoints of their own or else transparent byte-passing proxies that therefore preserve the properties of TLS between their peers as endpoints.
Concerning Message Confidentiality, I understood it as follows.
Use TLS to ensure message confidentiality over the wire.
Correct.
Use a symmetric encryption to encrypt the transmitted data.
TLS does that.
The encrypted data get stored in data base.
No. The encrypted data gets decrypted by the peer off the wire. The peer can re-encrypt to the database, or the database can do it, but that's a separate issue.
I am curious how to properly send username and password from a website login form to a server.
If I just send the username and password without hashing them to an https server how exposed is the password I send in a POST request to somebody sniffing the package and finding out the password? The server is https enabled.
What would be the proper methodology to do this?
If the server is HTTPS enabled then any data going over the wire will be encrypted. It would be extraordinarily difficult for a network-only attacker to sniff even a plaintext password over HTTPS without one of the parties noticing.
HTTPS uses SSL/TLS on the transport layer, which is designed to provide both encryption and authentication. The SSL/TLS protocol, as part of its handshake, negotiates a symmetric encryption key that is different for each session and is used with a strong algorithm to protect data on the wire.
To mitigate 'man-in-the-middle' attacks, the asymmetric keys used by the client and server to establish a shared encryption key are also cryptographically signed by a certificate authority, both to provide assurance of trust and to prevent modification of the certificate. As long as the certificate authority can be trusted, it is easy to check the signature and and server name on the certificate itself. All modern browsers do this automatically and throw a warning to the user if there is any problem with the certificate.
As long as you and your users are aware of the issues surrounding the proper use of SSL (e.g. keep your private key safe, and make sure your users pay attention to browser warning), it's fine to send plaintext passwords over an SSL connection.
If the demands of your application are such that you cannot do even that, you might consider X.509 authentication (which uses certificates on the client side as well as the server side) or Kerberos authentication (which sends no passwords over the wire). For a basic web application, though, both of these solutions are overkill.
Our clients call our web service over SSL and authenticate themselves with a username and password. Our server then generates a symmetric key and sends it back to the client.
Then, the client establishes a TCP connection to our server, and sends a login message. At this point, I want to authenticate the client.
My idea is to have the client encrypt a well-known/static piece of text with the symmetric key and use this as proof that it is in possession of the key.
Since the symmetric key is generated randomly, is it ok that I use a static piece of text here?
Any input appreciated.
SSL is built to authenticate both client and server, and asymmetric cryptography the most secure primitive you can use in this scenario. Symmetric ciphers can be used for authentication by using a Cipher Block Chaining Message Authentication Code other wise known as CBC-MAC mode. The use of CBC-MAC has similar protection as an HMAC, but utilizing a symmetric cipher instead of a message digest function. CBC-MAC mode is used by WPA to protect wireless networks.
Your idea is subject to a replay attack - if someone observes a user logging in, they can store the static-text-encrypted-with-symmetric-key and use it later to authenticate themselves.
The accepted way of doing this is a challenge/response. The client connects, the server generates a random challenge and sends it to the client, and the client responds with the encrypted version of the challenge (although you should actually use a HMAC here, rather than a block cipher, because otherwise your client is effectively a one-block decryption oracle!). It would also be safer to use two different random keys (provided at the same time over the web service), one for encryption and one for authentication.
Note though that this scheme, as written, is still susceptible to a man-in-the-middle attack. You are definitely better off using SSL, as The Rook suggests. This will require your client to generate a public key and send it to the web service. The web service responds with a signed certificate containing the client's public key along with the client's unique identifier (username, or whatever) in the DN field. The server on the separate connection verifies the client certificate used (ensuring it's signed by your web service), and verifies that the client identifier in the certificate matches the client that is asking to connect.