タグ付けされた質問 「tls」

MQTTは非常に用途が広いですが、それ自体も保護されていません。これは仕様によるものです。 Stanford-Clark氏によると、セキュリティを強化するためにセキュリティメカニズムをMQTTの周りに配置できることを彼とNipperが知っていたため、セキュリティは当初プロトコルから意識的に除外されていました。また、当時、スタンフォードクラーク氏は、気象観測所からの風速データなど、MQTTを介して送信される情報は特に保護する必要はないとしました。- ソース MQTTにラップできるセキュリティメカニズムの1つはTLSです。今日、ほとんどのブローカーがこれをサポートしています。もちろん、ラッピングメジャーによってオーバーヘッドが生じます。このオーバーヘッドは無視できる可能性があります（HiveMQブログを参照）。 現在、私のプロジェクトのMQTTの実行可能性を評価するために、TLSを介したMQTTと単純なMQTTのパフォーマンスの低下に関する情報（できれば信頼できる情報源）を探しています。特に、テクノロジーが多数の加入者に拡大する場合。 MQTT over TLSのパフォーマンスに関する有効なデータを取得するためのプロトタイピング以外の方法はありますか？

10 security  mqtt  tls 

インターネットアクセスの有無にかかわらず、ローカルネットワークに接続されたIoTデバイス（デフォルト設定、VPNなし、NATなし、DMZなし）を検討しています。私のデバイスは、認証と承認を備えたRPCメカニズムを提供するHTTPサーバーとして実行されます。それはmDNSでそれ自身を宣伝し、私は私のモバイルアプリまたは私のRaspberryPiを使用してそれに話します。 IoT開発の標準は相互（双方向）SSLを持つことです。 これは、一方向SSLではトラフィックを保護できないことを意味しますか？どうして？ ノート： 一方向SSLと双方向SSLの技術的な違いを理解していますが、IoTの生産で一方向（ほとんど）が考慮されない理由がわかりません。 ローカルデバイスに相互SSLを設定するのは難しいことを理解しています。サーバーの公開鍵と証明書をクライアントと共有する必要があり、その逆も同様です。一方、一方向の方が簡単に見えます（ユーザーの操作は必要ありません）。 Philips Hueのような一部の大量生産されたデバイスは、一方向SSL暗号化よりもローカルのhttpエンドポイントを開き、安全ではありません。なぜこの選択​​をするのでしょうか？ この質問は意見に基づくものではないと思います。この場合はお詫び申し上げます。

9 security  wifi  https  tls 

最近のペーパーA Smart Home is No Castle：Encrypted IoT Trafficのプライバシーの脆弱性によると、多くのスマートホームデバイスは接続パターンによって「フィンガープリント」される可能性があります。ほとんどのデバイスは呼び出されたときに少数のURLセットに接続するため、攻撃者（または不親切なISP）が各デバイスをいつ使用するかを特定する可能性があります。 たとえば、ホームルーターからAlexaサーバーに送信されるトラフィックを追跡しました（使用したURLは、ペーパーの図1にあります）。 また、同様の原理を使用して、スリープモニターが使用されたとき（したがって、ウェイクアップ/スリープ状態になったとき）、またはスマートスイッチが切り替えられたときを判断できることも示しています。 暗号化されているにもかかわらず、デバイスから多くの情報を取得できることは明らかに不安です。アクセスされるサーバーがはるかに多様であるため、コンピュータートラフィックから多くの情報を取得することは困難に思われますが、特定のサーバーにのみ「コールホーム」するIoTデバイスの場合、使用されたデバイスとそのタイミングを追跡するのは簡単なようです。 以来、多くの国がこのようなメタデータを格納し、それは彼らがあなたの活動を決定するために、このメソッド自体を使用することができるだろうことを実現可能だし、同じ量のデータは、任意のネットワーク・レベルの攻撃者に漏洩したことになります。 この方法でトラフィックがフィンガープリントされるのを防ぐ方法、または少なくとも抽出できる機密データの量を減らす方法はありますか？

8 privacy  https  tls 

Wi-Fi構成を含む初期構成用のWebページとアクセスポイントを持つ裏庭の庭師のためのRaspberry Piベースのデバイスを構築しています。接続はWPA2を使用し、その内部ネットワーク上の2つのデバイスのみがデバイス自体とユーザーの電話/タブレット/ラップトップになります。アクセスポイントは設定中にのみ表示され、外部の攻撃者が工場出荷時のランダムなパスワードを推測できる可能性が低くなります。だから私はトラフィックを暗号化しました、ほとんど確かに2つのノードだけ、短時間、そしてランダムなパスワードです。したがって、私が見ることができるHTTPSの必要はなく、HTTPを実行することを計画していました。 しかし、今日私は7月からChromeがすべてのHTTPサイトを安全でないとマークし始めることを知りました[1]。ただし、Wi-Fi構成はアクセスポイントによって行われるため、TLS証明書を確認するためのインターネットアクセスはまだ利用できません。これは、適切な操作に必要であると理解しています。[2] 証明書に自己署名することもできますが、これには別の問題があります。[3] だから私のオプションは次のようです： 大きくて怖い「このWebサイトは安全ではありません」というメッセージを設定ペ​​ージに表示します 大きくて恐ろしい「この証明書は信頼されていません」というメッセージ（たとえば、自己署名）を構成ページに表示します。 デバイス構成ページのデフォルトで、その素敵な緑の錠をどのように提供しますか？ [1] https://www.theverge.com/2018/2/8/16991254/chrome-not-secure-marked-http-encryption-ssl [2] /security/56389/ssl-certificate-framework-101-how-does-the-browser-actually-verify-the-validity?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa [3] https://www.globalsign.com/en/ssl-information-center/dangers-self-signed-certificates/

7 https  tls