BloodBlade あなたが議論したい内容が分からないのですが、以前の私の意見を改めて述べます。より安全な接続方法を実現するためには、誰かが積極的に推進する必要があります。5桁のパスコードを使用する人が増え続ける限り、提案された案は実用にならないでしょう。
HTTPSの大規模な普及は、複数の関係者が協力して実現した結果であり、多くの人がHTTPが暗号化されていないことによる危険性を認識し、ウェブサイトを安全にすることへの共識が得られた後に起こったものです。これは私が挙げた例です。
同様のケースとして、「GB」で始まる国家基準は、強制的な基準である。しかし、たとえ強制的な基準であっても、遵守するかどうかは個人の判断による。「GB/T」は推奨的な基準であり、遵守するかどうかは自由である。例えば、「GB/T 20234.3-2023 電気自動車用伝導充電接続装置 第3部：直流充電インタフェース」は、国内の電気自動車の急速充電インタフェースであり、この規格自体は強制的なものではないが、企業や一般の人々がこの規格を認めたことで、事実上すべての企業が遵守する基準となっている。ロシアでも使用されている。
いくつか明確に記述しておきたい点があります。誰かの推進や合意形成がない限り、どんなに素晴らしい・安全な提案でも、結局はただの日焼けだけになります。APRS-ISを使用しているほとんどの人が、依然としてパスコード認証を使用したり、計算機を選択したりします。それは、ある機能がいつ完成するかに関係なく、私たちがどう考えているかに関係なく成り立ちます。
問題は、なぜあなたがそう言ったのか、ということです。この機能は、もう何年も前から利用されています。皆さんはまだパスコードを使用していますか？私が調べたAPRSに関するチュートリアルには、資格認証について言及がないものばかりでした。なぜ、それが必要ないのでしょうか？
騒がしい状況が続く中、証明書認証は現在も実験的な機能であり、サポートされているSSLサーバーの数は減少しています。
以下は、DeepSeekからの抜粋です。
- 📌 重要な現状と注意点：
- 実験的な機能：ただし、これは現時点では実験的な機能であることをご理解ください。すべてのAPRS-ISサーバーがこれをサポートしているわけではありません。主にaprss.netの特定のサーバーのみがサポートしています。
- 対応範囲は限定されています。現在、この機能はARRL LoTWが発行する認証のみに対応しています。
- 利用可能性：最近のユーザーからの報告によると、この機能に対応する ssl.aprs2.net サーバーの数は減少しているようです。また、サーバー証明書の期限切れなどにより接続が失敗する可能性があります。
- 暗号化に関する考慮事項：一部の実装では、関連するアマチュア無線規制を遵守するために、NULL暗号（実際には暗号化されていないデータ）を使用することがあります。これにより、一部のクライアントとの互換性の問題が発生する可能性があります。
今の問題は非常に単純で、証明書認証機能が十分に完成していないため、誰も推奨しないのは当然です。
闽ICP备2021006864号-7
闽公网安备35020602002794号