On Mon, Mar 12, 2018 at 4:54 PM, Kadir Ozdemir <kozdemir@xxxxxxxxxxxxxx> wrote: > Hi Greg, > > Thank you for the comments. > > I have been recently made aware of msgr2. My knowledge about it comes > from http://docs.ceph.com/docs/master/dev/msgr2/. > > If the size of the plaintext data to be transferred over TLS is larger > than 16K, it is divided into chunks. The maximum size of the plaintext > chunk is 16K. TLS adds a small header to each record, the encryption > algorithms can add some more bytes, e.g., some padding, and also if > compression is enabled, the compression algorithm can add some more > bytes when the data does not compress well. There is no minimum size > for the plaintext data. So, small messages can be encrypted > individually, and sent immediately. This is what our code does > currently. Okay, so there will be some level of size inflation (because you can't meaningfully encrypt 4 bytes), but it won't force them to bundle up. That's good. We will want to identify what the size inflation looks like, though. Especially with the other encryption that may be coming down the pipe, this may nudge us to try and do some kind of coalescing between those protocol messages and outgoing user Messages. > > The OpenSSL library requires to specify if the SSL context would be > used by a client, server, or both (i.e., generic) when the SSL context > is created. A certificate to be used by an SSL context can be of type > client, server, or both. Assuming that not every environment would > support generic certificates, we decided to create separate SSL > contexts, one for initiating connections (i..e., for the client > role), and the other for accepting connections (for the server role), > even if the same certificate is used for both roles. > > After the servers have switched to "required", the clients can stay at > "desired" and it will work. However, it is recommend to switch the > clients to "required" too at some point. Otherwise, the clients would > be vulnerable to man-in-the-middle attacks, where the TLS connections > can be downgraded to the plain TCP connections. Ah, that is an interesting weakness of this approach. Our existing CephX message signing does mutual authentication, but of course that doesn't protect the messenger protocol-level bits... > There are two main reasons that our security team prefers separate > ports for TLS connections. The fist one is to eliminate any plaintext > message exchanges required to switch to TLS, and thus, eliminate any > vulnerabilities this may open up because of some software bugs. The > second one is the ability to block all plain TCP ports using firewall > rules to make sure that all connections are encrypted. ...which certainly argues in favor of just forcing it globally, even given the client configuration requirements. Personally, I'd like to see what that looks like and what kind of error messages we can generate if we have misconfigured clients trying to connect to TLS-only systems before we make a certain decision, though! :) > > Hope this helps. Yes, very much. Looking forward to seeing some code as soon as it can be shared for feedback. :) -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
