I have few questions on the above topics, Please can you help on understanding these things.
SASL/Plain can be used with and with out SSL. So if not use SSL then data is encrypted
and secured?
SASL/Plain with SSL then data will be secured and encrypted from both sides like from
client to server and server to client data? If encrypted from both side then how?
If only one way to the above question i.e from server to client encryption how above the data encryption from client to server?
Can we use two way SSL along with SASL/Plain or SASL/Scram?
If yes to the above question[4], In two way SSL, As we providing certificate from client side, this certificate it self providing the identity of client/user then why we need user name password again?
Thanks in advance.
If you don't see SSL, then data is exchanged in plaintext. With SASL/Plain that include your password!
Yes, with SSL both the client and server encrypt data when they send anything over the network
Not applicable
Yes you can and it is usually even recommended!
Both SASL and SSL can be used to authenticate users. You can use the mechanism you prefer. See the Kafka docs for details how to use them.
I recommend you check the Security section in the Kafka documentation that covers all these topics and gives examples.
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.
If I'm connecting to a mail server over SSL or TLS but using PLAIN authentication, is that secure?
Since the SSL/TLS connection is already encrypted, sending the password as PLAIN text doesn't hurt anything. You could encrypt the password as well, but then you're just double encrypting it. In most cases, I would consider that superfluous.
One case I can think of where you would use something other than PLAIN over SSL/TLS is if you choose to authenticate with certificates instead of passwords. Otherwise, I'd leave it at PLAIN.
Ryan is absolutely right if you are sure if you will never use your application without SSL. SSL is at the presentation layer and whenever a socket connection is established, SSL handshake is the first thing that happens which includes host verification, exchange of session keys and creating a secure transport layer. Communication at the application layer happens once this secure channel is established and the data that is exchanged is encrypted using the session keys and hence the communication is anyways secure.
However, if your application has an option to work with/without SSL then you should be encrypting your password separately. While working over SSL, this would be redundant but otherwise it is necessary.
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.
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.