Is it safe to use the HTTPS protocol for API interfaces?

Always know that HTTPS is more secure than HTTP, the data transmitted is encrypted Balalabala ...
Does my API interface use the HTTPS protocol to not have to decrypt the messages in the program?
Security score of 100 points, the following points will play a few
1, use HTTP directly
2, use HTTP, but use encryption and decryption function to decrypt the data
3, using HTTPS
4, using HTTPS, but also use the encryption and decryption function to decrypt the data

Reply content:

Always know that HTTPS is more secure than HTTP, the data transmitted is encrypted Balalabala ...
Does my API interface use the HTTPS protocol to not have to decrypt the messages in the program?
Security score of 100 points, the following points will play a few
1, use HTTP directly
2, use HTTP, but use encryption and decryption function to decrypt the data
3, using HTTPS
4, using HTTPS, but also use the encryption and decryption function to decrypt the data

1 = 50 points, no security, API content will be transmitted in clear text, and easy to hijack
2 = 60 points, add decryption function to consider the problem will be more, if only symmetric encryption, in fact, is not more secure than program 1 how much
3 = 90 points, in fact, this method should be called TLS, it is safe enough, the specific security mechanism can refer to this article
4 = 80 points, since TLS has been implemented, once again encryption is not improved for the complexity of the crack, but the loss of performance

The low-cost approach must be to use 3,https
If your API really has a lot of security requirements, you can also use HTTPS + yourself to implement encryption and decryption
I mean do not over-optimize, really necessary when this look at your business scenario

Note that HTTPS itself is involved in the process of encryption and decryption, involving asymmetric encryption, symmetric encryption, the entire process will be time-consuming
So the same interface using HTTPS is certainly slower than HTTP, a few to dozens of to hundreds of milliseconds, this you can test yourself.

HTTPS solve the problem is not just encryption, more importantly, authentication, prove that the server is really the server you want, your own encryption is not much use.
If you assume that the network is not secure, you can no matter how the encryption is useless, anyway, from the beginning of the secret key is looked at the light.
Asymmetric encryption may also be a bit of use, the exchange of keys is safe to complete, but HTTPS has been achieved, but also better, what do they do?

Is there any way to avoid web page sniffing password (man-in-the-middle attack)?

The above people from the encryption aspects of the security level assessment, I will be the cracker perspective of the comments:

1. Direct Visual analysis

2. Parsing Client decryption functions

3. Fake certificates for proxy forwarding

4. 3+2

HTTPS only guarantees the relative security of the transmission process, but far from talking about security.
As long as your code runs on the client, there is the possibility of being reversed.
All you can do is to complicate the client's encryption as much as possible ...

