I am using pyhthon3 requests library and want to request some resources from the server using HTTPS. So I use two way SSL authentication, and I have configured the server in a way which do not REQUEST for client certificate in response of 'client Hello' request.
As You can see IP xxx.xx.xxx.100 is the client and IP xxx.xx.xxx.207 is the server. So when the client sends 'Client Hello' to the sever, in response the server does not REQUEST for the client certificate, even though its two way SSL authentication.
So as per my requirements, how can I stop the process of handshaking and data sharing immediately in such case? Or how to force the server to REQUEST for client certificate?
... even though its two way SSL authentication.
It's not. Just because the client has the certificate to do mutual authentication, does not mean that this certificate is actually used. It is only mutual authentication if the server actually requests it using a CertificateRequest (which is clearly not done) and the client then providing the requested certificate.
... how can I stop the process of handshaking and data sharing immediately in such case?
You can't. There is no API for this.
And I'm not sure what kind of sense such a requirement would make. The client has successfully authenticated the server which should be all needed by the client to exchange data with the server. The server instead might want to know who the client is before sending specific data. So authenticating the client before providing such data makes sense from a server perspective, but not from a client one. This would be like you refusing to drive a car if nobody is checking your drivers license.
Or how to force the server to REQUEST for client certificate?
This fully depends on the kind of server. Different servers need different configuration. For example with nginx see ssl_verify_client.
If I use a SSL certificate for an API deployed to my own IIS server, it will protect my network, my ports, or only the data of the requests?
SSL/TLS certificates are a means of authentication. The certificat authority where you register your certificate (e.g. LetsEncrypt) will vouch that you indeed own the domain you are trying to register a certifiate for. These certificates are then used to bootstrap an encrypted TLS connection between the users of your server and your server. Subsequent data transfer is then encrypted (I assume this is what you meant by 'protected'?).
I am not sure what you mean by 'protecting' your network or port. Could you elaborate on that?
SSL is digital certificate provide authentication/authorization for a webapp/website for data and help to share information or "data" in Internet encrypted.
If you want protect a network, DMZ or demilitarized zone implementation helps you in Internet world.
When you apply SSL certificate and https for your web api in IIS. SSL handshake will be applied before the connection. So it will create a security channel to enhance the connection and avoid man-in-the-middle attack. At the same time, all the data are transmitted under encryption. So hacker won't be able to see th clear context because they don't have key to decrypt the information.
In a word, SSL secure connection and data not network. IIS client certificate can also be used to authenticate user identity.
When creating any kind of application web,api etc; This days the best practices recommend to secure endpoints by using TLS, but what we can learn from the cloudbleed issue, is that it may not be enough.
Therefore I would like to know what could be done to keep a certain level of security even when TLS is compromised.
For web applications what I currently use is jsencrypt, basically encrypts all data on client browser side before it is sent, but in order to to this I need first to exchange a shared secret (token/cookie) between the server and client, but when dealing with API's that don't support javascript what could be used?
Regarding the exchange of tokens, by instinct it may be obvious to say use OAUTH, OpenID Connect, json tokens , but all of them require or delegate trust to TLS, and again when this is compromised it became useless.
If I am right OpenID could be used without SSL to share a "common secret" by doing Diffie–Hellman key exchange, is there something similar that could be implemented keeping in mind that if TLS gets compromised, easy measure could be taking like revoking tokens or changing "salts" ?
For now I think by following the gpg or rsa (private/public) keys is the way to go, in a way that probably everyone could have access to the public keys but will not be available to see the content of some data signed to a specific user.
But question remains in how to exchange that very first "known secret" between client and server avoiding a possible man in the middle attack considering TLS can't be trusted.
The problem of exchanging the first "known secret" is the same for all protocols, SSL or not. SSL is a public key infrastructure where the basic information that needs to be distributed is the public key of the root certificate of the certificate issuer. The public keys for all ssl certificate issuers are distributed with the browser installation.
Any protocol will depend on some information that is communicated between the server and client in a different channel from the channel where the communication is established. If you don't trust the SSL infrastructure, you will have to send this information by email, postal mail, sms, or by some other means.
However, your problem does not start with the keys neccesary for the encryption libraries you are using in you web application. Your very web application (the javascript files) are also sent from the server to the web browser over SSL. If your SSL communication is compromised by a man-in-the-middle, this man-in-the-middle is also probably able to change the web pages and javascript code that you send to the browser. He could just rewrite your application and remove all encryption code, add new fields and messages for the user, send the user to a different site and so on.
The SSL infrastructure is really a cornerstone in web security, and a neccessity for web applications. Without it, you would have to build a custom protocol for sending encrypted web pages and write a custom browser that would understand this protocol.
With all that said, it is of course possible to add a tiny layer of extra security on top of SSL. You may i.e. create a private/public keypair for each user, send a public key to the user and encrypt all messages from your server to the user with the private key. This could protect against a scenario where a main-in-the-middle is able to listen to the communication but not able to change your messages.
I have a scenario where I have 2 applications.
The service, providing some data
The UI client, displaying the data from the service
I want the communication between the service and the client to be secure (encrypted).
What should I use for that? Is the SSL common protocol for such usage, or do we typically use something else?
Assuming your service is exposing a standard REST API (or similar) that your front-end is calling: yes, SSL is the standard. It provides:
Confidentiality: the data is encrypted between the client and the server and cannot be read by an attacker. Typically uses the RSA algorithm.
Integrity: an attacker cannot tamper with the messages sent between the client and the server. Typically implemented using HMAC
Authentication: the client is able to check that the server it is talking to is actually yours, and not an attacker. Basically, the server shows to the client a certificate signed by the Certificate Authority having issued the SSL certificate (e.g. VeriSign), that proves its identity.
All that is assuming SSL is configured properly on the server's side: up-to-date ciphers, no support for outdated ones, proper key length (2048 bits or higher), etc.
Note that a client can be anything calling your service: a browser-based application, a mobile application, a smart watch application...
You can use SSL Labs to check if your SSL configuration looks secure.
Whenever I see it being talked about, it sounds like one simply 'turns on' SSL and then all requests/responses to/from an online server are magically secure.
Is that right? Is SSL just about code - can I write two apps and make them communicate via SSL, or do you have to somehow register/certificate them externally?
Secure web pages are requested on port 443 instead of the normal port 80. The SSL protocol (plenty complicated in and of itself) is responsible for securing communication, and using the certificate information on both the SERVER and the BROWSER to authenticate the server as being who they say they are.
Generating an SSL certificate is easy. Generating one that is based on the information embedded in 99% of web browsers costs money. But the technical aspects are not different.
You see, there are organizations (Verisign, Globalsign, etc...) that have had their certificate authority information INCLUDED with browsers for many years. That way, when you visit a site that has a certificate that they produced (signed), your browser says:
"well, if Verisign trusts XYZ.com, and I trust Verisign, then I trust XYZ.com"
The process is easy:
Go to a competent SSL vendor, such as GlobalSign. Create a KEY and Certificate Request on the webserver. Use them (and your credit card) to buy a certificate. Install it on the server. Point the web-browser to HTTPS (port 443). The rest is done for you.
SSL is a protocol for encrypted communications over a TCP connection (or some other reliable scheme). The encryption uses public key encryption using X.509 certificates. SSL handles both privacy and trust. These are related: if you don't trust the server, you don't believe that the server hasn't handed out its private key to everyone in North America.
Thus, the client has to trust the server's certificate. For public sites, this is arranged via a hierarchy of certificate authorities, with the root authorities trusted, automatically, by browsers and things like the JRE's socket implementation.
Anyone can generate a self-signed certificate for a server, but then the client has to be manually configured to trust it.
SSL is not, in itself, a magic bullet that makes everything secure. Security has no such things.
SSL is, however, an already-designed, ready-to-use system for solving a common problem: secure stream communication over a network connection.
There are two things you need to do to secure your application with SSL:
Modify the application's code to use SSL.
Determine the certificate trust model (and deploy and configure the application respectively).
Other answers and documentation provide better answers to how to do each of these things than I could provide.
I'll throw caution to the wind and attempt to condense an enormous subject.
SSL attempts to solve two problems:
1) Authentication and hence trust i.e can the client trust the server and vice versa
2) Communication without eavesdropping
1) Is handled by means of an intermediary i.e a trusted 3rd party - these are called 'Root Certificate Authorities' ( or Root CAs ) examples include Verisign, RSA etc
If a company wants to authenticate users and more importantly if a user wants to authenticate the company's website it's connecting to i.e your bank then the Root CA issues the company a certificate which effectively says 'I the trusted Root CA verify that I trust that Company X are who they say they are and am issuing a certificate accordingly'. So you get a chain of trust i.e I trust the certificate from ACME Co because Root CA Verisign created and issued it.
2) Once the two parties have authenticated then the certificate ( typically X590 ) is used to form a secure connection using public/private key encryption.
Hopelessly simple and incomplete but hope that gives a rough idea
Yes and no. You should self-sign a certificate and test the site with SSL internally before deploying it with SSL, first of all. To make the public site secure under SSL, you will need to purchase a certificate from one of any number of certificate providers. Then you will have a certificate signed by a trusted third party, tied to your domain name, so that users' browsers won't complain that the certificate is invalid, etc. Turning SSL on is pretty much just flipping a switch, otherwise.
For the most part you need to buy and register a certificate externally.
You need to have your server certificate signed by a Certificate Authority (CA), for which they will charge you. The client needs to trust that CA and have a copy of the relevant CA public key. The client can then check that you are who you claim to be (including domain name (from DNS) and display name for https).
This is a good tutorial on how to create self signed certificates for Apache.
If you want to know how SSL works on either the Server or the Client, then I suggest Googling it. As you suspected, it is a ridiculesly complex procedure, with lots of communication between the client and server, a lot of very peculiar math, and tons of processing. There is also a lot of theory involved, several protocols and many different algorithms and encryption standards. It's quite incredible how changing http:// to https:// is so simple to the user, but results in so much work for both sides, and is so secure. To really understand it you need to take a security course (multiple courses to fully understand it), as the entire history of encryption goes into making your login to Gmail secure.
Turning on TLS (colloquially "SSL") does not make your site magically secure. You may still be vulnerable to application-level vulnerabilities like stack overflows, SQL injection, XSS, and CSRF.
As other answers have explained, TLS only protects against a man in the middle. Traffic between a client and a properly-configured TLS server cannot be intercepted or modified, and the client can reliably confirm the identity of the server by validating the X.509 certificate. This prevents an attacker from impersonating your TLS server.
SSL actually does two things:
Encrypts the communication so that an observer seeing the data stream will not be able to read the conversation.
Guarantees that you are talking to who you think you are talking to.
It is only for #2 that you need to get official certificates. If you only care to encrypt the communication without setting up a trust relationship, you can use self-signed certificates or you can use an algorithm that does not require certificates (i.e. Diffie-Hellman).