For securing NFS (Network File System), the mount option krb5p can be used to encrypt all traffic between the file server and the NFS client. Authentication and key exchange is based on Kerberos.
Here is an example on how to configure that for Debian: https://wiki.debian.org/NFS/Kerberos
Unfortunately, there seems to be no way to configure the cipher used for this transport enryption. What cipher is used and how can this be configured, selected, or enforced?
Without having used NFSv4 with Kerberos but used it in many other places, you are referring to confidentiality provided by the GSS-API through Kerberos which is implemented with gss_wrap(3)/gss_unwrap(3). It provides a quality of protection parameter but I am quite certain that NFSv4 will leave it null => at discretion of the mechanism.
Anyway, given that GSS-API completely abstracts from the mechanism, you probably have no choice but you still can do something about it. Enable in your KDC at least RC4, at best AES128 and AES256. Implementations will use best available cipher. You can scan traffic between the client and TGS (TGS-REQ and TGS-REP), client and server (NFS) to see which encryption type has been negotiated and this will highly be used for wrapping/unwrapping. You can always read the RFCs as I did but this will take a lot of time to understand.
Hope this helps. Of course, I could be completely wrong about NFSv4 internals.
Just made some digging and I am quite certain now that my analysis is correct. RFC 7530, chapter 3.2.1 talks about Kerberos 5 mandatory privacy for krb5p as well as AES along with HMAC-SHA1. Further reading leads to the RFC 2203 (RPCSEC_GSS spec) which talks about gss_wrap/gss_unwrap.
Related
I want to secure the communication between Thrift server and client instances. To achieve that, firstly I enabled SSL communication using keystore on the server-side and truststore on the client-side as explained in this post: https://chamibuddhika.wordpress.com/2011/10/03/securing-a-thrift-service/
Afterwards, I wrapped my transport instances on both client and server with TEncryptedFramedTransport.java class provided in the following SO post: Symmetric encryption (AES) in Apache Thrift. This enabled symmetric encryption of messages transferred through socket connection.
My question is that does applying both of these make my communication more secure? Or is it unnecessary to apply both and should go with only one of these?
There is a concept called "defense in depth". The idea is that you still have one more defense in place even when one might got broken. The downside is, as always, that you have to pay for it with performance.
The real question here is this: Do I trust SSL/TLS alone or do I absolutely want to add another (application-)level of security that serves as another hurdle if some man-in-the-middle manages to get inside my SSL/TLS channel, even if that will cost me some performance?
Another aspect could be that might be forced to communicate across unsecure channels, i.e. when there is no TLS available. Remember, Thrift allows to switch transports as needed, and the SSL/TLS infrastructure is only available in certain cases.
If the answer is yes, do it. It would be the same answer with REST, SOAP, XMLRPC, Avro, gRPC or the well-known avian carriers.
So the final, decisive answer if you should do that depends on your priorities.
Be also aware that there could also be other attack vectors in your solution that might need to be adressed.
I have a project where data sent between two peers needs to be encrypted. I dont need to authenticate the server or the client , I just need my data to be unreadable on the network.
I have two options:
1- Secure socket
- Open a secure socket
- Write clear data
2- Socket
- Open a socket
- Encrypt data
- Write encrypted data
Is there a performance benefit in using a secure socket instead of "normal" socket in which I write encrypted data? (let's say i'm using the same cipher in both case)
No, there is no difference with regards to speed when it comes to the algorithms used. In general you'd need authenticity, integrity and authenticity of messages in a transport protocol. Generally after the initial handshake this is performed by symmetric algorithms in a rather efficient manner.
Creating your own transport protocol is so fraught with danger that the chance of creating and implementing a secure protocol by a novice is about zero. For instance, if you don't know about plaintext or padding oracle attacks then you may loose confidentiality of the message, basically leaving you with messages without any protection.
So check the fastest TLS 1.2 or 1.3 ciphersuites and use that. You may want to check what Google has introduced to TLS; they've really focussed on speed and security.
(Note that a secure socket without authentication allows a man in the middle (MITM) to intercept and thus see in the clear your data.)
A secure socket will take longer to establish, then taken about the same to encrypt. So performance wise, if you have a pre-shared symmetric encryption key, you would benefit a from skipping the ssl/tls handshake and go directly to tcp socket. That would show as a big speedup for numerous short connections, in particular if they were not using sslcontext and session resumption (lots of JSSE jargon, I know, but I keep it obscure because this you know or you don't, here is not the place).
However, if you don't have a pre-shared key, the whole handshake is really something you shouldn't avoid.
Can anyone how kerberos works. any manual regarding kerberos . What is the size of packet size, what encryption is done and what are the sizes of keys etc.
Regarding Kerberos request and reply packet size - they are generally very small, typically around 50 - 100 kilobytes. To understand how Kerberos works, think of a triangle. At one point of the triangle, you have the Kerberos Key Distribution Center (KDC). After you have proven your identity to the KDC, it hands out a ticket to you - you being the internal network web browser user or SSH user. You are the second point on the triangle. This Kerberos ticket allows you access a Kerberos-protected service (such as HTTP or SSH) running on an application server on your network. The "application server" in this scenario, is the third point of the triangle. Two of the early and arguably most important contributors/creators of Kerberos, Clifford Neuman & Theodore Ts'o, from MIT at the time, explain how Kerberos works in this guide: Kerberos: An Authentication Service for Computer Networks. Literally, just a few paragraphs down from the top of the article is a section titled, "How Kerberos works". This is not really a manual. It explains the Kerberos main concepts. The article is dated but all concepts still apply. For "a manual", you need to ask yourself what you're trying to do. Integrate a Java web application to Kerberos (using Microsoft Active Directory)? Something else? For the former, which is very popular combination, I suggest reading this: Java-based Integrated Windows Authentication w/ Kerberos SPNEGO. As mentioned, Kerberos request and reply packet sizes are generally small. Encryptions types available are DES through AES and more, encryption key sizes are 40-bit to 256-bit lengths and more, though anything smaller than 128-bit length is out of favor now. Take a look at the Kerberos Network Authentication Service (V5) - RFC 4120. Though not an easy read, the article contains embedded references which will explain all of this. This question was far too broad, as samiles has said. Please try to start off with a specific programming example next time.
In Best practice for secure socket connection, the OP wants to secure the connection between two sockets, without SSL.
Thomas Pornin suggests SSH is the answer.
Is this answer based on SSH port forwarding of existing sockets, or just switching to SSH in general?
If not, and the question was how to make existing sockets more secure without SSL, what is the best way to to do that?
If a client on port 10 connects to a server on port 20, how can the server restrict access so that only client on port 10 can connect? And that it really is the client on port 10 (not an imposter)? (Availability only for an authenticated client).
The answer there is any form of the SSH protocol, which is based on channels. You can use those channels to transmit fairly arbitrary information, including port-forwarded data or terminal sessions, or anything you can turn into a byte stream. That said, TLS is generally much easier to implement in code because the libraries are ubiquitous and designed to be used this way. SSH is easier to implement in scripts on Unix-like systems because it has a powerful command-line API.
In most cases, TLS is the better choice. Unless you have a very specialized problem, TLS is almost always the better choice. So the question here is, what problem do you have that TLS doesn't work for? If it's "I hate TLS" then sure, SSH. But TLS is better in most cases.
TLS authenticates using client certificates. SSH authenticates using your private key. In either case, the cert/key is stored in a file that the client reads and uses to authenticate to the server.
It's not clear from your question what you mean by "client" or "imposter" here. Anything that has access to the cert/key will be authorized (possibly requiring a user-provided password), so those must be protected. If when you say "client" you mean "my application," that is not a solvable problem. You can authenticate people. You can to some extent authenticate machines (particularly if you have an HSM or similar piece of security hardware available). You can weakly authenticate that client is claiming to be on port 10, but this is generally useless and extremely fragile, so I wouldn't pursue it. You cannot authenticate software over the network in any meaningful way.
Short answer, though, is to use TLS unless you have a very specialized problem and a good security expert to help you design another solution (and your security expert will almost certainly say "use TLS").
I am considerung to use zeromq as messaging layer between my applications. At least in some cases I want the communication to be secure and I am thinking about SSL.
Is there some standard way how to ssl-enable zeromq? As far as I understand it doesn't support it out of the box.
It would be nice if I just had a parameter when connnecting to a socket (bool: useSsl) :)
Any ideas?
Understanding that this is not really an answer to your question, I'm going to be encrypting the messages directly with RSA, before sending them with 0mq.
In the absence of a more integrated encryption method that is fully tested and implemented in my platform of choice, that's what I'm going with. 0mq just recently released version 4, which has encryption baked in, but it's still considered experimental and isn't fully supported by the language bindings.
Encrypting the message, rather than the connection, seems to provide the simplest upgrade path, and the difference for our purposes are pretty much just semantics given how we'd have to implement encryption currently, today.
Edit: I know more about encryption now than I did when I wrote this, RSA is not an appropriate choice for encrypting message data. Use AES, either with manually sharing keys (this is our approach for the short term) or implementing a key sharing scheme as in Jim Miller's answer... but beware if you take the latter approach, designing and implementing a key-sharing scheme securely is hard. Way harder than you'd think. You can implement SSL/TLS directly (using message BIOs), and others have done so, it's also not simple but at least know that the SSL scheme is industry standard and therefore meets a minimum security requirement.
In short, before the Elliptic Curve crypto baked into ZMQ 4 is considered reliable and becomes standard, the "accepted solution" would be to implement SSL/TLS over the connection manually, and failing that, use AES 128 or 256 with a secure key sharing mechanism (key sharing is where RSA would appropriately be used).
We are currently implementing a pre-shared key solution using 0mq that implements a key exchange protocol based loosely on TLS/SSL.
Essentially, we have a data aggregator service that publishes encrypted state of health data over a multicast 0mq publisher. A symmetric key is used (AES128) to encrypt the data and can be retrieved from a second service running as a simpler request/response model over 0mq.
To retrieve the symmetric key (PSK), we are implementing the following protocol:
Client connects
Server sends its certificate
Client verifies server certificate against a CA chain of trust
Client sends its certificate
Server verifies client certificate against its CA chain
Server encrypts PSK using client public key
Server sends encrypted PSK to client
Client decrypts PSK
Once a client has the PSK, it can decrypt the messages retrieved over multicast.
We are also looking at implementing a session expire algorithm that uses two enveloped keys in the multicast service. One key is the current session key, and the second is the old, expiring key. That way, a client has a little more time to retrieve the new key without having to buffer encrypted messages before retrieving the new key.
According to zeromq.org, it's not supported yet but they are looking into it. It looks like it's suggested as a project for Google Summer of Code.