I'm developing a product that needs to act as a server over a local network for other client applications to connect to, under the following constraints:
The data exchanged is very valuable, and we have no guarantee over the security of the users' network or the machine acting as a server. Therefore any SSL certificate could potentially fall into "the wrong hands".
To minimise disruption to the user experience, any non-electronic means of identifying the server to the client should be limited to information that can be written on a post-it (i.e. IP address, passcode rather than exchanging key files).
Given these, our current SSL strategy is:
Do not install any SSL certificates into any trusted stores or sign any certificates against a CA certificate - this could give a potential attacker a front-door key to all the client machines
SSL certificates will therefore be self-signed. This offers no man in the middle protection, because we have no way of verifying the server. It does however offer eavesdropping protection to those users who have insecure networks but secure servers.
Implement a "passcode" system over the top using Rijndael symmetric encryption, so even if the certificate is compromised there is some eaves-dropping protection (I know, many leaky buckets - but better than nothing). This passcode can be regularly regenerated with minimal interruption to the user experience of the clients.
Within these constraints, is there a more secure strategy for the client and server to communicate?
In the end we developed a system where we could generate a new SSL certificate in memory for each channel we were going to support. This cannot provide protection against Man in the Middle but does at least protect against eavesdropping (unless the third party has access to the memory of the server at time of transmission, in which case all security is moot anyway!).
Related
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
I have a WCF service to receive sensitive data ( like SSN,Name,address,Driver License), To make sure information is securely transmitted and not accessible for anyone to view/change, I need to install SSL server certificate on clients server.
I am looking for recommendations to choose correct certificate for service. there are couple of certs available online
1. Standard cert
2. Extended validation certificate.
3. SSL Plus
4. Extended validation plus
The level of validation (i.e. domain, organization, extended, etc.) of an SSL certificate has only meaning to an end user; a simple domain validation certificate will let you setup a secure communication between you clients and your server.
The higher validation levels only give to a human more confidence about the site he / she is visiting, because a higher certificate level means that the organization has passed through more checks than with a simpler certificate.
If you're concerned about data communication security (and if you need it between two programs, without direct user intervention), you should instead turn your attention to encryption protocols and key lengths.
According to Qualys SSL Labs Best Practices, you should use 2048-bit RSA or 256-bit ECDSA private keys (I suggest you to read the whole guide).
As in all processes that involve encryption, higher levels of encryption means higher security, but lower performance, so choose wisely.
After you have chosen and installed the certificate, be sure to check your server with their SSL Server Test, to be sure that your whole encryption chain is secure enough and correctly configured.
I'd like to run some encrypted connections between some of my own servers. One can use Curl (or some other mechanism) to connect using HTTPS without SSL certificate verification. I'm using PHP, but the language probably isn't significant for this question.
I'm assuming using HTTPS without a SSL certificate is atleast more secure than doing the exact same connection over plain HTTP, since atleast it's encrypted and an evildoer would have to make a much larger effort to intercept en decrypt the information.
As far as I know an SSL certificate only says "this trusted third party says the server you connect to is owned by the guys that claim to own it". If I connect using my own domainname or IP address, I know I'm the owner. What additional value does an SSL certificate provide if I'm the owner of both ends of a connection?
Not verifying the identity of the server you connect to leaves the connection open to potential MITM attacks. SSL/TLS can be used without certificates (with anonymous cipher suites), but they're insecure (and disabled by default); as the TLS RFC says: "Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated."
In addition, the HTTPS specification itself expects there to be an X.509 certificate.
Checking the identity of the remote party is a necessary element for securing your system. It's not very useful to exchange data secretly with a remote party who may not be who they claim they are (even if the secrecy is guaranteed).
This being said, you don't have to go via a commercial CA. You can either use self-signed certificates, which you would have to import individually into each client as trusted certificate, or create your own institutional CA. There are tools to do this, ranging from OpenSSL's CA.pl (see man-page), TinyCA or OpenCA amongst others. Some operating systems also provide their own small CA capabilities.
If I connect using my own domainname or IP address, I know I'm the
owner. What additional value does an SSL certificate provide if I'm
the owner of both ends of a connection?
The certificate assures you that you're indeed connecting to your machine and that the traffic hasn't been intercepted. That's why you need to check that it's a certificate that you recognise.
SSL certificates are more for the piece of mind of your customers or those using your site. In either case, the data is being transmitted over the same connections - it's just a matter of whether or not a third party is certifying you as being safe.
At my last job, we did all of our internal data transfers at my last job via https/ftps but did not have an SSL certificate until very recently. Since the data transfers were internal, it made no difference.
I'm implementing a client with python's twisted that checks the server ssl certificate when connecting, following basically this recipe. I've seen in many HOWTOs such as this one the server checking the client's authenticity through a ssl certificate as well. Currently i authenticate my clients using an unique id and 1024 char string (they are automated clients without human interaction).
What I don't understand is what reason would I have to use the whole ssl thing for this instead of just sending the "password" to the server. After all the connection is already ssl encrypted, checking the server certificate and everything. This is a similar question but I want to know why people use ssl client certs and not just what is the best way to do it instead.
A client certificate restricts access to people authorized with certificates. Assuming your certificates are distributed and managed correctly, this makes it more difficult to connect from an unauthorized location (or say, a bot network), since you need more than just a username and password.
Client-side certificates are a potential part of a defense-in-depth strategy, if you are in an environment where you can manage client certificates.
Certificates are easy to revoke. Passwords can be stolen, but stealing a client side certificate would be much harder.
Using client certificate based mutual authentication prevents at least the following attacks/problems:
Phishing the password
Key logging the password
Shoulder surfing the password
Guessing the password
Password reuse on several services
Additionally, using client certs gives you the possibility to store client certificate (and the matching private key) on a smartcard, USB token or other hardware security module (HSM), thereby going from "something you know" (password) to "something you possess physically" (token, card) plus "something you know" (PIN). This is also called two-factor authentication.
In your specific case of using passwords as shared keys in a technical, system to system communication link, using certificates has two advantages:
scales better: with shared keys, every node has to share a different key/password with each other node, resulting in (n-1)! passwords, while with certificates, each node needs only one certificate and private key (n certificates plus a CA)
the possibility of storing the key on a HSM and thereby prevent it from being copied/stolen digitally.
The main advantage of client-side authentication (i.e. when server checks client certificate) is that if server gets compromised, the client's secret, which is private key for certificate, won't be compromised. Whereas if client uses credentials they could be compromised along with server.
Owning SSL certificates that are signed by a certificate authority means that the SSL certificate owners have gone through the hassle of being verified by the CA that the owner is who they say they are. For instance, if you have an ecommerce store called widgetsdeluxe.com and you have a certificate for the domain widgetsdeluxe.com that has been signed by Verisign, et. Al., shoppers will know that when they go to that site and the name on the certificate matches the actual domain name they went to, then they can trust that the information is secured and is coming from the widgetsdeluxe.com domain (this is to prevent spoofing and man-in-the-middle attacks).
I am trying to understand what's the actual difference between SSL and Kerberos authentications, and why sometimes I have both SSL traffic and Kerberos.
Or does Kerberos use SSL in any way?
Anyone could help?
Thank you!
SSL uses public key cryptography:
You (or your browser) has a public/private keypair
The server has a public/private key as well
You generate a symmetric session key
You encrypt with the server's public key and send this encrypted session key to the server.
The server decrypts the encrypted session key with its private key.
You and the server begin communicating using the symmetric session key (basically because symmetric keys are faster).
Kerberos does not use public key cryptography. It uses a trusted 3rd party. Here's a sketch:
You both (server and client) prove your identity to a trusted 3rd party (via a secret).
When you want to use the server, you check and see that the server is trustworthy. Meanwhile, the server checks to see that you are trustworthy. Now, mutually assured of each others' identity. You can communicate with the server.
2
While Kerberos and SSL are both protocols, Kerberos is an authentication protocol, but SSL is an encryption protocol. Kerberos usually uses UDP, SSL uses (most of the time) TCP. SSL authentication is usually done by checking the server's and the client's RSA or ECDSA keys embedded in something called X.509 certificates. You're authenticated by your certificate and the corresponding key. With Kerberos, you can be authenticated by your password, or some other way. Windows uses Kerberos for example, when used in domain.
Keep in mind: Recent versions of SSL are called TLS for Transport Layer Security.
To put simply, Kerberos is a protocol for establishing mutual identity trust, or authentication, for a client and a server, via a trusted third-party, whereas SSL ensures authentication of the server alone, and only if its public key has already been established as trustworthy via another channel. Both provides secure communication between the server and client.
More formally (but without getting into mathematical proofs), given a client C, server S, and a third-party T which both C and S trust:
After Kerbeos authentication, it is established that:
C believes S is who it intended to contact
S believes C is who it claims to be
C believes that it has a secure connection to S
C believes that S believes it has a secure connection to C
S believes that it has a secure connection to C
S believes that C believes it has a secure connection to S
SSL, on the other hand, only establishes that:
C believes S is who it intended to contact
C believes it has a secure connection to S
S believes it has a secure connection to C
Clearly, Kerberos establishes a stronger, more complete trust relationship.
Additionally, to establish the identity of S over SSL, C needs prior knowledge about S, or an external way to confirm this trust. For most people's everyday use, this comes in the form of Root Certificates, and caching of S's certificate for cross-referencing in the future.
Without this prior knowledge, SSL is susceptible to man-in-the-middle attack, where a third-party is able to pretend to be S to C by relaying communication between them using 2 separate secure channels to C and S. To compromise a Kerberos authentication, the eavesdropper must masquerade as T to both S and C. Note, however, that the set of trusts is still unbroken according to the goal of Kerberos, as the end-state is still correct according to the precondition "C and S trusts T".
Finally, as it has been pointed out in a comment, Kerberos can be and has been extended to use SSL-like mechanism for establishing the initial secure connection between C and T.
In short:
Kerberos usually does not encrypt transferring data, but SSL and TLS do.
"there are no standard APIs for accessing these messages. As of
Windows Vista, Microsoft does not provide a mechanism for user
applications to produce KRB_PRIV or KRB_SAFE messages." - from
http://www.kerberos.org/software/appskerberos.pdf
In opposite, SSL and TLS usually do not transfer and proof Yours Windows domain login name to the server, but Kerberos does.
A short answer: SSL and Kerberos both use encryption but SSL uses a key that is unchanged during a session while Kerberos uses several keys for encrypting the communication between a client and a client.
In SSL, encryption is dealt with directly by the two ends of communication while in Kerberos, the encryption key is provided by a third party - some kind of intermediate - between the client and the server.
From http://web.mit.edu/kerberos/:
Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.
Meanwhile:
SSL is used for establishing server<-->server authentication via public key encryption.
From https://www.eldos.com/security/articles/7240.php?page=all,
Kerberos and TLS are not the things to compare. Their have different objectives and different methods. In the beginning of our article we mentioned the frequently asked questions like “which is better” and “what to choose”. The former is not a question at all: nothing is better and everything is good if you use it in a right way. The latter question is worth a serious consideration: what to choose depends on what you have and what you want.
If you want to secure your communications in a sense that nobody can read it or tamper it, perhaps the right choice is to use TLS or some other protocols based on it. A good example of TLS usage for securing World Wide Web traffic carried by HTTP is to use HTTPS. For secure file transferring you may use FTPS, and take into account that SMTP (though it stands for a “simple” mail transfer protocol, not “secure”) is also may be protected with TLS.
On the other hand, if you need to manage user access to services, you may want to use Kerberos. Imagine, for example, that you have several servers like Web server, FTP, SMTP and SQL servers, and optionally something else, everything on one host. Some clients are allowed to use SMTP and HTTP, but not allowed to use FTP, others may use FTP but don’t have access to your databases. This is exactly the situation when Kerberos is coming to use, you just have to describe user rights and your administrative policy in Authentication Server.
SSL authentication uses certifiactes to verify youself to server whereas Kerberos works entirely different.
SSL can be imported manually and added as per configurations in client and host manually.
Whereas kerberos is authentication where no password are transmitted over network. Here kerberos KDC server doesn't need to communicate with any service or host to verify the client. Client uses principle stored in kerberos to communicate with kerberos server. In return kerberos server provides ticket using keytab of other server stored beforehand. In the other server, the client provides the ticket and services matches the ticket with their own keytab and verify the client.
Simply put,
SSL is to encrypt the data so that the data cannot be understood by someone who is trying to steal it out in the network.
Kerberos is a network authentication protocol which helps in authenticating a client to talk to server without sharing any password/token during the time of the request.