RFC /advice：关于安全/不安全 RPC/事件流协议设计
对于我想做的事情来说，SSL 似乎相当臃肿，而且我对 OpenSSL 怀有强烈的仇恨（NSS 可能有用）。我需要在两个节点之间打开一个 TCP 通道，该通道将用于 RPC/加密的 RPC/事件流/加密的事件流。我使用协议缓冲区来定义和复用不同的流量源。
我一开始就不想使用 SSL。我需要经过身份验证的安全密钥建立（经过身份验证的 diffie-hellman），然后可能需要一个基于块密码的流对象来加密和解密加密的事件流和加密的 RPC。
我的第一个想法是，通过构建 SSL 实现来节省编码时间和设计时间，前提是我可以从 SSL 实现获取套接字句柄并将其用于未加密交换和加密交换。但这最终可能会是一个丑陋的实现，据我所知，这样做可能与 ssl 协议不兼容（即 TCP 状态和 SSL 状态之间的强耦合）。
我的第二个想法是，通过打开多个套接字来节省编码时间和设计时间。但众所周知，多套接字协议设计是邪恶的。
第三个想法是，我将加密所有内容，但所讨论的服务具有高性能事件交换机的能力，并且它还有一个在同一台计算机上运行的数据库服务器。这种方法的开销并不令人满意，因为大多数流量都是明文的。
所以，这些方法对我来说似乎并不令人满意。因此，我得出的结论是，使用 cryptopp 和 boost::asio 我可以推出自己的解决方案并构建自己的协议（我已经必须这样做）。我是一位非常有能力的系统程序员，并且我有一位了解加密技术应用的工程师。
我完全赞成重用，在这种情况下，我希望可以重用 SSL，但我认为我不能。如果您能根据您在类似情况下的经验（您必须设计或研究过网络协议）向我提供任何建议，我将不胜感激。给我印象最深的建议得到了勾选。：
D p.s.，我的应用程序还需要执行一些奇特的加密，无论如何我都会引入 cryptopp。
SSL seems quite bloated for what I want to do, and I have a passionate hatred for OpenSSL (NSS might be useable). I need to open a TCP channel between two nodes that will be used for RPC / encrypted RPC / Event streams / Encrypted event streams. I am using protocol buffers to define and multiplex the different traffic sources.
I don't want to use SSL to start with. I need authenticated secure key-establishment (authenticated diffie-hellman) and then perhaps a block-cipher based stream object to encypher and decypher encrypted event streams and encrypted RPC.
The first thought that I had was, save coding time and design time by building on an SSL implementation, provided that I can get the socket handle from the SSL implementation and use it for unencrypted exchanges as well as encrypted exchanges. But this will probably end up to be an ugly implementation, and for all I know doing this might be incompatible with the ssl protocol (i.e., strong-coupling between TCP state and SSL state).
The second thought I had was, save coding time and design time by opening multiple sockets. But as we all know multi-socket protocol design is evil.
The third thought was, I'll just encrypt everything, but the service in question serves in the capacity of a high performance event switch and it has a database server running on the same machine as well. The overhead of this approach doesn't satisfy as the majority of traffic will be cleartext.
So, these approaches don't seem satisfactory to me. Therefore, I have come to the conclusion that using cryptopp and boost::asio I can roll my own solution and construct my own protocol (which I already have to do). I am a pretty capable systems programmer and I have an engineers understanding applying encryption techniques.
I am all for reuse, and in this case I wish I could reuse SSL, but I don't think I can. Any advice you can give me from your experience in similar situations (you must have designed or worked on a network protocol) will be appreciated. The advice that makes the biggest impression on me gets the tick.:D
p.s., My application also needs to perform some exotic encryption for which I am pulling in cryptopp anyway.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您当然可以重复使用 SSL - 不会与 TCP 状态发生不良耦合。您可以在任何您喜欢的底层流上使用 SSL，唯一的依赖是它必须是双向的。
最简单的方法是使用 SSL 库，该库允许您提供自己的发送/接收函数，当 SSL 库有要发送或接收的加密端数据时，将调用该函数。然后，您可以通过将 SSL 数据包装在您自己的底层协议中的特殊帧内来实现这些功能。
（我只熟悉 OpenSSL 库如何执行此操作 -
SSL_set_bio()函数 - 但我确信其他 SSL 实现也允许类似的操作）。但请注意，协议的密钥协商部分的计算开销（无论是通过 SSL 还是自行部署）将远远超过实际的分组密码加密/解密，因此“加密所有内容”可能并不那么重要。损失如你所料。
You certainly can re-use SSL - there is no untoward coupling with TCP state. You can use SSL over any underlying stream you like, the only dependency is that it must be two-way.
The simplest way to do so will be to use an SSL library that allows you to provide your own send/receive functions to be called by the SSL library when it has encrypted-side data to send or receive. You would then implement these functions by wrapping the SSL data within special frames within your own underlying protocol.
(I am only familiar with how the OpenSSL library does this - the
SSL_set_bio()function - but I am sure that other SSL implementations allow something similar).Note though that the computation overhead of the key-agreement part of the protocol - whether done through SSL or roll-your-own - will far outweigh the actual block cipher encryption/decryption, so "encrypt everything" may not be as much of a loss as you expect.