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

5
MQTTプロトコルを使用するタイミングと理由
温度、湿度、質量を測定するデバイスを開発しています。現在、HTTPSを使用してデータをリモートサーバーにアップロードしています。「モノのインターネットのプロトコル」であると主張されているMQTTと呼ばれるプロトコルがあることを私は知っています。 どのような場合、なぜHTTPSからMQTTに切り替える必要がありますか?

1
ESP8266高速HTTP GET応答率
ESP8266のプログラミングを開始してサーバーから継続的に変化するデータ(車の位置)を取得しているときに、問題が発生しました:ESP8266がサーバーからデータを1秒あたり3回以上受信できません。 データレートは15回/秒が望ましいでしょう。受信したデータは、47要素の文字列です。 #include <ESP8266WiFi.h> #include <WiFiClient.h> // WiFi information const char WIFI_SSID[] = "my-wlan"; const char WIFI_PSK[] = "123qwe123qwe"; // Remote site information const char http_site[] = "10.13.137.144"; const int http_port = 8080; // Pin definitions const int LED_PIN = 16; // Global variables WiFiClient client; String readString, readString1 ; ...

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

2
MQTTまたはHTTPを使用する必要がありますか?
私は、温度や湿度などの環境から情報を感知して収集するデバイスを開発しています。 デバイスは電源に接続されていませんが、バッテリーとそれを充電するソーラーパネルを備えています。 ほとんどの場合、ほとんどディープスリープ状態にあり、データを検知して転送する必要がある場合にのみ起動します。この操作には約1〜2分かかり、その後再びスリープ状態になります。 私はこの分野の専門家ではありませんが、トピックからのメッセージを常に受信するためにデバイスにアクセスできる必要がある場合、MQTTは良いオプションになるはずですが、私のシナリオではセンサーを読み取り、データを定期的にサーバー。 現在、HTTP経由でデータを送信していますが、MQTTを実装するのが理にかなっているのでしょうか。このシナリオでは、HTTPよりもメリットがありますか?
9 mqtt  protocols  https 

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

4
リアルタイムおよび履歴センサーデータを視覚化するIoTプラットフォームはどれですか?
学生向けのチュートリアルを準備するために、IoTの分野でいくつかのDIYエレクトロニクスプロジェクトに取り組んでいます。ESP32、ESP8266、Arduino Uno、Raspberry Piを使用したい。私はファームウェア/ハードウェアの部分に詳しいので、クラウドアプリケーションの経験はありません。 Azure IoT、AWS、GoogleなどのIoT PaaSがあることを知っています。いくつかの単純なプロトタイプを開発したいので、データをクラウドに送信して、バックエンドのコーディングスキルなしでそれらを視覚化したいだけです。上記のサービスでは、データ(DB、UI / UXなど)を表示するために追加の専門知識が必要です。 私はググって簡単な解決策を見つけ、これらのサービスがポップアップしました: uBeac TagoIO ThingsBoard フリーボード myDevices 負けた 物事 ティンガー HTTPおよびMQTTを介してクラウドサービスにデータを送信し、送信されたデータを視覚化する必要があります。 私の質問は、どのサービスが自分のユースケースに適しているかです。他に見逃したサービスはありますか?そしてより重要なのは、そのようなサービスを評価するための重要な要素は何ですか?

1
インターネットにアクセスせずにアクセスポイントを実行しているWebベースのデバイス設定でHTTPSを使用するにはどうすればよいですか?
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 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.