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.
Related
I'm trying to understand more why I shouldn't use WCF transport security over the internet. From the answer here I'm told the chain of hops may not be secure. But isn't transport security just like https (which is widely used on the internet)? Or maybe I should ask, what is the difference between wcf transport and https?
If I need to explain myself clearer, please comment.
Thanks
Transport security is indeed very similar to HTTPS (and identical in many cases). What it provides you is an encrypted tunnel between your client and the server. Providing there's a direct connection from your client to your server, it's perfectly fine (providing that your client verifies that it got the right server certificate). If your client is talking to another intermediate server, on which you rely to pass the message to your server - then that intermediate server would get unencrypted data.
An example :
You have a company that processes payments. Because of some regulations, you need servers in each country, and those in turn pass the requests to your main server in the US.
You want to make sure that even if the local hosting company tries to find out what details are being passed, they can't.
That is what Message Security provides you - you trust only the client and your main servers, so you want only them to be able to encrypt and decrypt.
With Transport Security, there would be two transitions - the client will encrypt, and the intermediate server will decrypt. Then it will encrypt again, and your main servers will decrypt. As you can see, there is an intermediate phase where the data is plain in RAM in the intermediate server.
This MSDN article describes it very well, and where to use each :
MSDN
Look at another answer on the link you gave. It explains that the case where transport security not sufficient is when the client doesn't check server certificate. I quoted the answer below:
Yes it is 100% secure when the clients (which most clients do) validate the server certificate.
The multiple hop scenario mentioned here is complete bogus. This is only true when the same message travels through various applications. Like for example several application brokers. If these brokers do not communicate securely then the message can be read by intermediate network sniffers.
In other words, client/server communication over the internet is 100% secure even when there are a million routers in between but it is only secure when the client validates the server certificate as the client could connect to a man-in-the-middle host that could impersonate the server with a false certificate. If the client does not validate the certificate the message could be compromised.
I'm trying to understand more why I shouldn't use WCF transport security over the internet
You should not because (Quoting from here).
Transport Security
Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between client and the service, each intermediate point must forward the message over a new SSL connection.
Message Security
When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.
I was trying to do this with Java RMI over SSL, but later I discovered that SSL certificates will provide host level authentication and NOT process level authentication.
Also, I was storing the keystore's password in configuration; so the certificates can be used by another attacker process and it can get authenticate.
An X.509 certificate used for SSL/TLS could potentially be used to identify something else than a host name (this is already typically done for client certificates).
There are two types of verification involved when establishing an SSL/TLS connection to a server:
The certificate verification itself: this verifies that the certificate is trusted and valid for the required purpose at the time of use, usually with a PKI as described in RFC 3280/RFC 5280.
The host name verification: once it trusts the certificate to be genuine, the client checks that it's for the server it was looking for. This is protocol specific (e.g. RFC 2818, Section 3.1 for HTTPS), but has been generalised for most protocols in RFC 6125. (This is similar to checking that the picture on a passport matches the name in front of you, instead of just accepting any valid passport.)
By default, Java's SSLSockets don't perform the second step unless you add something to do it. (In Java 7, some new SSL parameters allow you to do so within the trust manager, but only for specific protocols.)
What you'd need is to find a way to define how you want to identify your other applications and processes, using something else than the host name, issues certificates with these naming conventions, and have your client application check this.
You should be able to implement your own identity verification mechanism within anSSLSocketFactory, before returning the sockets in each method, an use that factory for your RMI application, as described here: https://blogs.oracle.com/lmalventosa/entry/using_the_ssl_tls_based1
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.
The ColdFusion documentation is weak on how and when to use it. What does it do? How does one use it?
Update: it seems to be broken, as outlined in Washing Client Certs in ColdFusion with SOAP – Part 2.
problems with CFHTTP handling SSLv3 sessions
Client certificates are a bit of a pain because of the overhead involved in using it.
As Jura says, you'll need a target server that uses client certificates as a mechanism for authentication. This server side piece does not need to be CF-based. The web server (IIS, for example) would be set up to require this. This is part of the SSL/TLS protocol, not specific to any language at the application level.
You would use this if the server you are requesting a resource from requires client certificates. The administrator of that server would need to give you the client certificate and private key ahead of time. As mentioned by user349433, this is commonly a PKCS12 (.p12 or .pfx) file.
The server will validate that the client certificate is "trusted" and if it is, it will allow the TLS/SSL handshake to proceed, and CF will be able to write the HTTP request on top of it.
The use case today is to prevent man-in-the-middle attacks, but because of the overhead involved with certificate distribution, revokation, etc. it's not terribly common.
If you want to know more about it, check out TLS 1.1 specification:
https://www.rfc-editor.org/rfc/rfc4346
https://www.rfc-editor.org/rfc/rfc4346#section-7.4.6
You are using client certificate in case if the target server uses that mechanism for authentication. You'll need to obtain specific client certificate from the service provider in order to be able to connect to the service. It's been used for some internet banking applications back in days I believe. Not sure what is the use case today for it, may be distributed corporate networks where you need to connect to corporate server over internet in a highly secure manner?
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.