バックグラウンド
デバイスの安全なリモート構成を目的として、ハードウェアの内部に配置されるHTTPSサーバーを実装しました。これを実現するために、既存の軽量組み込みTCP/IPスタックをオープンソースSSLライブラリと一緒に使用しました。その上にあるWebサーバーは、私が完全にゼロから作成したものです。(これは車輪の再発明のように見えるかもしれませんが、私たちの目的のためには、非常に軽量で、特定の機能のセットが非常に狭い必要があります。たとえば、使用している組み込みRTOSやROM「ファイルシステム」との互換性。これは、HTTP(S)セッションとSSLコンテキストで利用できるのは数百キロバイトで、数メガバイトではないシステムです。すべてのことを検討し、他のさまざまな製品を検討した後、独自の製品を作成することは理にかなっています)。このWebサーバーは、5〜10個の同時ソケット接続(つまり、5〜10個の同時または永続的なHTTP接続)のみをサポートする必要があります。これは、ハードウェアが処理できる量とほぼ同じです。ボックスを管理するために1人か2人だけがアクセスできるように設計されているため、これは問題ありません。
現在、すべてがうまく機能しています。HTTP1.1に必要と思われるRFC2616をできるだけ多く実装するようにコーディングしました。現時点では、5つのHTTPSポート(443)でリッスンしているだけで、ポート80からリダイレクトするものはまだ実装していません。
最初の質問-リダイレクト
HTTPからHTTPSへのリダイレクトに関する記事を数え切れないほど見ましたが、これを行うために既存および従来のWebサーバーを構成する方法に関する記事を読んだことがあります。私が解決したいのは、これをプログラムで実装する必要があるため、プロトコルレベルでどのような手法が使用されているかです。
一般的な方法は、301/302応答を発行することのようです。したがって、私が考えていた戦略は、例として、8つの同時リクエストのリソースがあると仮定した場合です。
ポート443でHTTPS接続をリッスンします。最大6つの同時HTTPS接続(6つのソケット)が利用可能です。
ポート80でHTTP接続をリッスンし、最大2つのHTTP接続(したがって、ポート80で2つのソケット)を使用できます。ポート80のソケットの場合、実際のWebサーバーには実際にはアクセスされません。
\r\n\r\n
代わりに、またはが表示されるまで(要求ヘッダーの終わりを示す)ソケットから読み取りを続けてから、\n\n
301(または302)応答を返します。これは、私のコードではほとんどハードコードされたconst char*
文字列です。次に、ソケットを閉じます。これらの2つのポート80ソケットは、純粋にリダイレクトの目的で存在します。
この戦略は賢明に聞こえますか?
現時点で私が確信していないのは、301/302応答にリダイレクトURLが含まれていることだけです。このハードウェアの「ボックス」は、家の中やルーターの後ろに置いて、ダイナミックDNSサービスなどを介してアクセスできるデバイスです。では、プログラムで「外の世界」に相当するHTTPSURLを決定するにはどうすればよいでしょうか。おそらく、リクエストURIとhost:
元のHTTPリクエストヘッダーのフィールドの組み合わせを使用することによってですか?
上記で問題が発生した場合は、代わりにHTMLの小さな部分を提供することをお勧めします。これには、ブラウザーからURLを取得することでHTTPSリダイレクトを実行するJavaScriptが少し含まれています(具体的には、どのJavaScriptメソッドを使用しますか)。これを行うために私は手に負えないことを思い出せませんが、私はそれを何年も前にやりました)。(現時点では、指定できる特定のドメインがないことを考えると、SSL証明書がどのように機能するかはわかりませんが、後で、おそらく別のSOの質問でそのブリッジを通過する予定です。)
2番目の質問-HTTPとHTTPSを提供する
これはおそらく、プログラミングの質問というよりも、設計の質問の方がはるかに多いか、顧客が何を望んでいるのかということですが、とにかくここに入れて、人々の意見を確認したいと思いました。私の問題は、クライアントがボックスに「SSLが必要」と単純に述べていることですが、それ以上のものではありません。たとえば、SSLを使用するかどうかをエンドユーザーに選択できるようになることを期待しているかどうかはわかりません。実際に質問する前に、何が質問されるかを予想しているだけなので、事前に知識と答えを身に付けておきたいと思います。言い換えれば、この仕様を書いている人々は「南京錠を見たいだけ」と「SSLが欲しい」ということです。これは明らかに良いことです。
まず第一に、SSLを使用した中途半端な解決策のようなものはないことを私は知っています。つまり、すべてを持っているか、何も持っていない必要があります。つまり、HTTPSを介して重要なものを提供することで、小さなプロセッサが実行する必要のある作業を減らすことにしたが、HTTPを介して画像とCSSファイルを提供するとします。いくつか読んだ後、私は今、これが多くの理由で絶対にノーノーである理由を正確に知っています。
ただし、最初のログインページでHTTPSまたはHTTPのいずれかを選択する機能をエンドユーザーに提供した場合はどうなりますか?「HTTPS」を選択すると、安全なHTTPSログインページにリダイレクトされます。これは、たとえば携帯電話からボックスにアクセスするときにアクセス速度を上げるために、ユーザーがセキュリティを侵害することを選択した場合に提供する便利なオプションです。この最初のページでは、「安全なログイン」と「標準の安全でないログイン-推奨されません」などの両方が提供される場合があります。明らかに、これはユーザーに関する限り脆弱性を開きますが、SSL接続も危険にさらしますか?つまり、この最初のログインページはHTTP経由で提供される必要があるため、おそらく攻撃者は理論的にはボタンを入れ替えるようにそれを壊す可能性があります-そのようなことです。したがって、HTTPSはHTTPSを意味する必要があります最初から?私がHTTPSをこのことに靴べらにして機能させることができ、それが最新のブラウザー(IE8 / 9、FF)で使用するように特別に設計されていることを考えると、通常のHTTPアクセスが必要な実際的な理由はありますか?代替として提供されますか?