SSL は非常に複雑なので、ライブラリを使用する必要があります。
Keyczar、Botan、cryptlibなど、いくつかのオプションがあります。これらのライブラリ (または Boost.Asio や OpenSSL など、他の人が提案したライブラリ) のそれぞれに、このためのサンプル コードがあります。
2 番目の質問 (あまり苦労せずにライブラリを既存のコードに統合する方法) への回答: 現在のコードに依存します。int
Winsock または socket メソッドを呼び出してsなどを送受信する単純な関数が既にある場合はstrings
、それらの関数の中身を書き直すだけで済みます。そしてもちろん、ソケットをセットアップするコードを最初から変更します。
一方、Winsock/socket 関数を直接呼び出している場合は、同様のセマンティクスを持ちながらデータを暗号化して送信する関数を作成し、Winsock 呼び出しをそれらの関数に置き換えたいと思うでしょう。
ただし、 Google Protocol BuffersやApache Thrift (別名 Facebook Thrift)などへの切り替えを検討することをお勧めします。Google の Protocol Buffers のドキュメントには、「プロトコル バッファが登場する前は、リクエストとレスポンスのハンド マーシャリング/アンマーシャリングを使用するリクエストとレスポンスのフォーマットがあり、多数のバージョンのプロトコルをサポートしていました。これにより、非常に醜いコードが作成されました。 ...」
現在、ハンド マーシャリング/アンマーシャリング フェーズにあります。それはうまくいく可能性があり、実際に私が取り組んでいるプロジェクトはこの方法を使用しています. しかし、それをライブラリに任せる方がはるかに良いです。特に、将来的にソフトウェアを更新することをすでに考えているライブラリです。
このルートに進む場合は、SSL ライブラリを使用してネットワーク接続をセットアップし、それらの接続を介して Thrift/Protocol Buffer データをプッシュします。それでおしまい。大規模なリファクタリングが必要になりますが、維持するコードが少なくなります。私が言及したそのプロジェクトのコードベースに Protocol Buffers を導入したとき、約 300 行のマーシャリング/デマーシャリング コードを取り除くことができました。