RFC/advice : 보안/비보안 rpc/이벤트 스트림 프로토콜 설계

Question

SSL은 내가하고 싶은 일에 대해 꽤 비대 해 보입니다. OpenSSL에 대한 열렬한 증오심이 있습니다 (NSS가 유용 할 수도 있음). RPC/암호화 된 RPC/이벤트 스트림/암호화 된 이벤트 스트림에 사용될 두 노드 사이에 TCP 채널을 열어야합니다. 프로토콜 버퍼를 사용하여 다른 트래픽 소스를 정의하고 다중화합니다.

시작하려면 SSL을 사용하고 싶지 않습니다. 인증 된 보안 키 설정 (인증 된 diffie-hellman)과 암호화 된 이벤트 스트림 및 암호화 된 RPC를 암호화하고 암호 해독하기위한 블록 암호 기반 스트림 객체가 필요합니다.

첫 번째 생각은 SSL 구현에서 빌드하여 코드 작성 시간과 디자인 시간을 절약 할 수 있었지만 SSL 구현에서 소켓 핸들을 가져 와서 암호화되지 않은 교환 및 암호화 된 교환에 사용할 수 있다고 가정했습니다. 하지만 이것은 아마도 추악한 구현이 될 것이며,이 작업을 수행하는 것이 SSL 프로토콜 (즉, TCP 상태와 SSL 상태 간의 강력한 결합)과 호환되지 않을 수도 있습니다.

두 번째 생각은 여러 소켓을 열어 코딩 시간과 디자인 시간을 절약 할 수 있다는 것입니다. 그러나 우리 모두가 알고 있듯이 멀티 소켓 프로토콜 설계는 나쁜 것입니다.

세 번째 생각은 모든 것을 암호화 하겠지만 문제의 서비스는 고성능 이벤트 스위치의 기능을 담당하며 데이터베이스 서버는 동일한 시스템에서 실행됩니다. 이 접근법의 오버 헤드는 대부분의 트래픽이 일반 텍스트이므로 충족되지 않습니다.

그래서 이러한 접근 방식은 나에게 만족스럽지 않습니다. 따라서 cryptopp와 boost :: asio를 사용하여 자체 솔루션을 롤아웃하고 내 자신의 프로토콜을 구성 할 수 있다는 결론에 도달했습니다 (이미 수행해야 함). 저는 꽤 유능한 시스템 프로그래머이며 암호화 기술을 적용하는 엔지니어를 이해하고 있습니다.

나는 모두 재사용을위한 것이며,이 경우에는 SSL을 재사용 할 수 있기를 바랄 수 있지만 그렇게 할 수는 없다고 생각합니다. 유사한 상황 (네트워크 프로토콜을 고안했거나 작 업 했어야 함)에서의 경험을 통해 저에게 줄 수있는 조언을 주시면 감사하겠습니다. 내게 가장 큰 인상을주는 충고는 다음과 같습니다. : D

p.s. 내 응용 프로그램은 어쨌든 cryptopp를 가져 오는 이국적인 암호화를 수행해야합니다.

Answer 1

확실히 SSL을 다시 사용할 수 있습니다. TCP 상태와 관련성이 없으므로 쉽게 연결할 수 있습니다. 원하는 기본 스트림에서 SSL을 사용할 수 있지만 유일한 양방향성은 양방향이어야합니다.

이렇게하는 가장 간단한 방법은 보내거나받을 암호화 된 쪽 데이터가있을 때 SSL 라이브러리에서 호출 할 자신의 보내기/받기 기능을 제공 할 수있는 SSL 라이브러리를 사용하는 것입니다. 그런 다음 자신의 기본 프로토콜 내의 특수 프레임에 SSL 데이터를 래핑하여 이러한 기능을 구현할 수 있습니다.

(OpenSSL 라이브러리가이 작업을 수행하는 방법 (예 : SSL_set_bio() 기능에만 익숙하지만 다른 SSL 구현이 비슷한 것을 허용합니다).

프로토콜의 키 - 합의 부분의 계산 오버 헤드가 SSL 또는 자체 롤을 통해 이루어 졌는지에 관계없이 실제 블록 암호화 암호화/암호 해독보다 중요하므로 "모든 암호화"가 아닐 수도 있습니다 당신이 예상하는만큼 많은 손실이 있습니다.