Does the SSL protocol require a challenge to check whether the subjected machine has access to its private key?
I recommend reading the paper A first few milliseconds of an HTTPS connection. It describes the handshake quite well. You can also fire up wireshark and follow along.
Only in 2 way authentication. Take a peek at this image for the "standard" SSL handshaking and note the lack of a client private key (none is needed). In the 2 way authentication handshake the client must prove it's identity in the same way the server does as per that diagram.
In general the client doesn't need a private key since symmetric keys are created after the servers identity is verified.
Related
I am trying to set the client to nodes SSL encryption for one of our client.
I have confusion regarding the functionality of setting require_client_auth in client_encryption_options in cassandra.yaml and what configuration needs to set from client and cassandra node in case I set require_client_auth to true.
Password authentication is already set,now investigating if there might be any additional advantage to having both ("authenticator: PasswordAuthenticator" and "require_client_auth: true") turned on
As Jim stated, require_client_auth doesn't have anything to do with Cassandra's auth system. It is an additional level of security configuration for client-to-node SSL.
When you implement client-to-node SSL and enable require_client_auth you are enabling what is known as Two Way SSL. Instead of the Cassandra client simply verifying the identity of the server, the server also verifies the certificate used by the client. This doc One Way and Two Way SSL and TLS (Peeples K. 2015) has a good description of this process:
Two-way SSL authentication is also referred to as client or mutual authentication because the application acting as an SSL client presents its certificate to the SSL server after the SSL server authenticates itself to the SSL client.
Establishing the encrypted channel using certificate-based 2-Way SSL involves:
A client requests access to a protected resource.
The server presents its certificate to the client.
The client verifies the server’s certificate.
If successful, the client sends its certificate to the server.
The server verifies the client’s credentials.
If successful, the server grants access to the protected resource requested by the client.
On the other hand, with One Way SSL the client only verifies the server's certificate (from the same doc).
The advantage of Two Way SSL would be in knowing that the Cassandra nodes will not allow a connection from an unknown client certificate.
IMO, one Way SSL still offers a decent degree of security. The dev team will need to present a cert which validates up through the same CA (certificate authority) as the cert from the Cassandra nodes. Two Way SSL might be useful in a large org, helping to keep out connections from applications that have not first talked with your team.
I believe the require_client_auth is for SSL (certificate) communication between the client and server, and that the client must identify itself (you can have it so that the server is the only one that identifies itself).
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 am new to PKCS#11 and Common Access Cards but as I understand it, on the card you have the certificates(s) that can be extracted and the private key(s) that can't. I am trying to write an app that communicates with a web server that requires certificates for authentication. The PKCS library provided from the hardware vendor is pretty thin. I can essentially access the certificate object or sign data using the on-card private key.
What I am unsure of how I handle the handshake and such when connecting to the webserver. Am I supposed to provide the certificate along with something else signed by the private key? If so, what is it that I sign with the private key? I have Googled this but have been unable find some kind of explanation for this process.
If you are using an RSA key on the common access card for authentication, you'll need to send a CertificateVerify message in the handshake, which contains digital signatures over the handshake records to that point. You'll also need to send the client certificate, of course. See §7.4.8 of the TLS specification for details.
Hopefully, your TLS library supports the use of a PKCS #11 cryptographic module. If not, you might have to switch. Implementing TLS yourself when you aren't familiar with the specification is unreasonable.
I think you just need to retrieve your client certificate from your PKCS#11 device and then use it along the request you are making to web server. You don't need to implement SSL if you use existing libraries. They should contain all you need.
I am developing an API for a web application. Desktop clients will interact with the API using simple HTTP posts (REST). I will be using SSL, there is no question about that. My question is this: should I also be encrypting the data before it is sent over SSL? The information being sent may contain confidential information. Is SSL enough or should I be doing more? My only concern with adding additional layers of security is that it will make it substantially more difficult for people to interact with the API. Any thoughts on this would be much appreciated.
No, SSL provides strong encryption as it is. Just make sure you force clients to use HTTPS, and if you're really paranoid, check if the cypher is strong enough.
The only reason you'd want to encrypt a second time is if your web application passes the data straight on to some other system. In that case, you could keep the web application ignorant of the actual data and provide end-to-end encryption between the client and the final destination.
If you trust your certification authority, your clients do, and your key is sufficiently secure (RSA 2048 will not be breakable for a while), there are no problems at all with SSL. You don't need to encrypt your data before SSLing, as SSL itself provides encryption.
If this API is to be used over the internet, the list of certification authorities here will be useful to you in choosing one.
You can also have your clients authenticate over SSL, with SSL client certificates.
IMHO, I would not add another layer of encryption on top of the already existing encryption. It will add overhead and as you say, complexity to the API. SSL exists to send secure data between two nodes, so why reinvent the wheel?
As Shtééf already pointed out, if you need end-to-end encryption instead of point-to-point then you need encryption. Other cases this might be relevant in is if your client application communicate with the server through integration services and service busses. In this case the SSL encryption is not enforced while the message is in an intermediary node and that node may do whatever it wants with the unencrypted confidential data.
Furthermore, if your clients use these integration services then they might not enforce SSL connections between the client and the integration service.
While working with highly confidential information I tend to go for end-to-end security instead of SSL encrypted communications channels for this reason.
Yes.
SSL would help with man-in-the-middle and wiretapping but there are other attacks SSL won't help with such as replay attacks.
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).