Showing posts with label VPN. Show all posts
Showing posts with label VPN. Show all posts

Jun 14, 2026

OPNsenseで、OpenVPNサーバ設定・起動

OpenVPNサーバー設定・起動手順の総まとめです。


決定版:OpenVPNサーバー設定・起動手順

1. サーバー用証明書の作成

サーバー自体が使用する証明書を事前に作成します。

  • [System] > [Trust] > [Certificates] を開き、[+ Add] をクリック。

  • 以下の通り入力して [Save]

    • Method: Create an internal Certificate

    • Descriptive name: 任意(例: OpenVPN-Server-Cert

    • Certificate authority: 事前に作成した CA証明書 を選択

    • Type: Server Certificate

    • Common Name: クライアントが実際にアクセスする 「WANのグローバルIPアドレス」または「ドメイン名(ホスト名)」 を入力(※空欄不可)

    • Alternative Names (IP addresses): 空欄 で可

2. OpenVPN サーバー(Instance)の追加

  • [VPN] > [OpenVPN] > [Instances] を開き、画面右上の [+] ボタンをクリック。

  • 起動に必要な各セクションの項目を以下の通り入力・選択します。(記載のない項目はデフォルトのままで問題ありません)

■ General Settings(基本設定)

  • Description: 役割が後から一目で判別できる、分かりやすい任意のメモ・備考(例: Remote-Access-VPN)を入力

  • Role: Server

  • Protocol: UDP

  • Port: 1194

  • Device type: tun

  • Bind address: 空欄(自動ですべてのインターフェースで待ち受けます)

■ Authentication & Encryption(認証と暗号化)

  • Certificate: 手順1で作成した サーバー用証明書 を選択(※証明書内にCA情報が含まれるため、CAを別途選ぶメニューはありません)

  • Authenticators: Local Database(OPNsense内のローカルユーザーで認証を行う場合)

■ ネットワーク設定 & Routing

  • Server (IPv4): VPNクライアントに割り当てる仮想IPアドレスプール(例: 10.0.8.0/24 ※既存のLANと重複しない範囲、空欄不可)

  • Routing > Local Network: VPN経由で接続・アクセスを許可する、実際の自宅や社内のLANアドレス範囲(例: 192.168.1.0/24

  • Routing > Remote Network: 空欄(拠点間VPNではなく、リモートアクセス運用の場合は不要です)

入力が完了したら、最下部の [Save] をクリックします。

3. ファイアウォール規則の追加(手動)

Instancesから手動作成した場合は、通信を許可するルールを自分で2箇所追加する必要があります。

  1. [Firewall] > [Rules] > [WAN][+ Add] をクリック。

    • Protocol: UDP

    • Destination Port Range: 1194 から 1194

    • Description: 任意(例: Allow OpenVPN WAN)で保存・適用。

  2. [Firewall] > [Rules] > [OpenVPN](または生成されたVPNインターフェース)で [+ Add] をクリック。

    • Protocol: any(すべて許可、または必要に応じて制限)

    • Description: 任意(例: Allow VPN Traffic)で保存・適用。

4. サーバーの起動確認

  • [VPN] > [OpenVPN] > [Connection Status] などの画面で、作成したインスタンスのステータスが有効(Enabled)かつ 「Status: running」(緑の再生マーク等)になっていることを確認します。


以上、Geminiコメント

OPNsenseで、OpenVPNリモートアクセス設定

CA証明書とサーバ証明書がすでに準備できている状態で、残りの手順をGeminiに解説してもらい、少しだけ編集を加えた。
--------------------------------------------------------------------

残りの設定手順を、大きく5つのステップに分けて解説します。

これまでの確認事項(OPNsense 26.1.6、英語UI、IPv4限定、全通信をVPS経由にしてセキュリティDNSで保護する構成)をすべて反映した、決定版の設定手順書です。

手元での整理や今後の運用の記録としてお役立てください。

OpenVPN Remote Access Setup Guide (OPNsense 26.x)

Step 1: Create a User & Client Certificate

現在のバージョンでは、ユーザー作成と証明書の発行を個別のメニューで行い、Common Name を使ってシステム内部で紐付けます。

1-1. Create the User

  1. System > Access > Users に移動し、右上の (Add) をクリックします。

  2. 以下の項目を入力します。

    • Username: 任意のユーザー名(例: vpnuser

    • Password: 任意のパスワード

  3. 画面最下部の Save をクリックします。

1-2. Create the Client Certificate

  1. System > Trust > Certificates に移動し、右上の (Add) をクリックします。

  2. 以下の通り設定します。

    • Method: Create an internal Certificate

    • Descriptive name: 識別しやすい名前(例: vpnuser_cert

    • Issuer: 事前に作成済みの CA証明書 を選択

    • Type: Client Certificate

    • Common Name: Step 1-1で作成した Username と完全に一致する文字列 を入力

  3. 画面最下部の Save をクリックします。

Step 2: Configure the OpenVPN Instance (Server)

すべてのトラフィックとDNSクエリをVPS上のOPNsenseに集約するための核心的な設定です。

  1. VPN > OpenVPN > Instances に移動し、右上の (Add) をクリックします。

  2. 各セクションの項目を以下のように設定します。

[General Settings]

  • Description: 任意の識別名(例: VPS_Secure_VPN

  • Role: Server

  • Protocol: UDP

  • Port: 1194(デフォルト)

[Cryptographic Settings]

  • SSL/TLS Service Certificate: 事前に作成済みの サーバ証明書 を選択

[Authentication Settings]

  • Authentication: Local Database を選択

[Server Settings]

  • Server (IPv4): VPNクライアントに割り当てる仮想IP帯(例: 10.8.0.0/24

    ⚠️ 自宅のLAN環境(192.168.x.xなど)と絶対に重複しない独立したネットワークを入力してください。

[Routing Settings]

  • Local Network: 【空欄】(すべての通信をRedirectするため指定不要)

  • Redirect gateway: default を選択

    💡 これにより、出先や自宅からのすべてのインターネット通信がOPNsense(VPS)を経由するようになります。

[DNS Settings]

  • DNS Servers: 1.1.1.2, 9.9.9.9 など(セキュリティ機能付きDNSのIPを個別に入力)

  1. 画面最下部の Save をクリックし、ページ上部に表示される Apply changes を押します。

Step 3: Configure Firewall Rules

外からのVPN接続を受け入れ、接続後にインターネット(WAN)へ通信を抜くためのファイアウォールとNATの設定です。

3-1. WAN Side Rule (外部からの接続許可)

  1. Firewall > Rules > WAN に移動し、 (Add) をクリックします。

  2. 以下の通り設定します。

    • Action: Pass

    • Protocol: UDP

    • Destination: WAN address

    • Destination port range: From 1194 To 1194

  3. Save をクリックします。

3-2. OpenVPN Side Rule (VPNからインターネットへの通信許可)

  1. Firewall > Rules > OpenVPN に移動し、 (Add) をクリックします。

  2. 以下の通り設定してVPNからの全通信を通します。

    • Action: Pass

    • Protocol: any

    • Source: any

    • Destination: any

  3. Save をクリックし、画面上部の Apply changes を押して反映させます。

3-3. Outbound NATの確認

  1. Firewall > NAT > Outbound を確認します。

  2. モードが Automatic であれば自動でVPNセグメントもNATされます。もし ManualHybrid にしている場合は、Step 2で設定したVPNの仮想IP帯(例: 10.8.0.0/24)がWANへ抜ける(Interface: WAN, Source: VPNネットワーク, Translation: WAN address)割当ルールが存在することを確認してください。

Step 4: Export Client Configuration

PCやスマホにインポートするための設定ファイル(.ovpn)を出力します。

  1. VPN > OpenVPN > Client Export に移動します。

  2. Remote Access Server: Step 2で作成したインスタンスを選択。

  3. Export type: File Only を選択。

  4. 画面下部の Accounts / Certificates に Step 1 のユーザー名が表示されていることを確認します。

  5. HostnameにターゲットVPNサーバのホスト名またはIPアドレスを設定します。

  6. その横にある Cloud/Download ボタン(ダウンロードアイコン) をクリックしてファイルを保存します。

Step 5: Client Connection Test

  1. 利用するクライアント端末(PC、スマホ等)に公式アプリ OpenVPN Connect をインストールします。

  2. Step 4で出力した .ovpn ファイルをアプリにインポートします。

  3. Step 1-1で決めた UsernamePassword を入力し、トグルスイッチをONにして接続します。

接続後の確認

接続完了後、クライアント端末のブラウザ等で以下の確認を行ってください。

  • 「確認君」などのIP確認サイトにアクセスし、表示されるグローバルIPアドレスがVPS(OPNsense)のものに変わっていること

  • DNSの漏洩確認サイト(dnsleaktest.com など)で、クエリの送信元が Step 2 で指定したセキュリティDNS(CloudflareやQuad9)になっていること。

Jun 13, 2026

OPNsenseを、さくらのVPSで立ち上げる

はじめに

  • さくらのVPSの管理画面でOS再インストールを選択

.isoから、OPNsenseを選ぶ

ネットワークのアサイン(二枚目NICの接続先等)は、「現状維持」が手堅い

  • さくらのVPSのパケットフィルタはOSイントールで無効に?

さくらのVPSのパケットフィルタで自宅からのhttpsのみ許可

OPNsenseのメニューでshellを選択

pingやtracerouteで外部接続可を確認

tcpdump -nn port 443 で自宅から到達するか確認

  • OPNsenseのメニューで設定

Jun 24, 2022

solved: openvpn error, failed to negotiate cipher with server

Error message in syslog

Month DD hh:mm:ss kalp ovpn-my_config[15328]: OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's cipher ('AES-128-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305') if you want to connect to this server.

Solution

If you can't update all of server(s) and clients,

the next best method is to do the following actions to them.


$ sudo vi  /etc/openvpn/client/my_config.ovpn

cipher AES-128-CBC  # existing 

data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC # newly added line

$ sudo /etc/init.d/openvpn restart


Then everything started to be okay.

--> 07/04 加筆編集

Backgrounds

For those who want to know the reason a bit further …
もう少し理解を深めたい方へ 
 
The error came from incompatibility of ciphers among different versions of OpenVPN on servers and clients.
You will need to verify each versions and then study which countermeasure among 1,2,3 below can be taken.
In my case, I took the countermeasure 2 for my some reasons.
サーバ~クライアント間のOpenVPNバージョンの違いによってサイファが非互換であることが、不具合のきっかけです。
まず、それぞれのバージョンを調べて下記の対策1, 2, 3 のいずれが可能か考えます。
私の場合は、諸事情で2を選択しました。

 

Countermeasure 1
The best countermeasure is to update both server/client to OpenVPN 2.5.
Even with the default settings, the appropriate cipher will be automatically selected when connecting.
最善の対策は、サーバー/クライアントともOpenVPN 2.5にアップデートすることです。
デフォルト設定のままでも、接続時に適切なサイファが自動的に選択されます。

 

Countermeasure 2 (if updating to 2.5 is not possible)
Add "data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC" (for OpenVPN 2.5 or later)
or "cipher AES-128-CBC" (for OpenVPN 2.4 or earlier)
to all server and client settings Please add "cipher AES-128-CBC". This will allow the connection to be established using AES-GCM as the cipher.
対策22.5へのアップデートが不可能な場合)
すべてのサーバーとクライアントの設定に
data-ciphers AES-256-GCM:AES-128-GCM:AES-128-CBC」(OpenVPN 2.5以降の場合)
または「cipher AES-128-CBC」(OpenVPN 2.4以前の場合)
を追加してください。これにより、サイファとしてAES-GCMを使用して接続が確立できます。

 

Countermeasure 3 (If updating to 2.5 is not possible + you really want to use BF-CBC)
You need to explicitly enable BF-CBC in the configuration on the OpenVPN 2.5 side (add BF-CBC to data-ciphers).
However, this is not recommended since BF-CBC will most likely not be available in future OpenVPNs.
対策32.5へのアップデートが不可能+どうしてもBF-CBCを使用したい場合)
OpenVPN 2.5側の設定で BF-CBC を明示的に利用可能にする必要があります(data-ciphers  BF-CBC を追加する)。
しかし、今後のOpenVPNでは BF-CBC は利用できなくなる可能性が高いので、この方法は推奨されていません

 

Source

“OpenVPN 2.5 のサイファの互換性
https://www.openvpn.jp/2020/10/29/1370/

 

Mar 12, 2020

信頼していたVPNが悪用された場合に何が起きるのか、記事

https://www.fujitsu.com/jp/solutions/business-technology/security/secure/column/202002-1/index.html

Pulse Secureの「情報漏えいの脆弱性(CVE-2019-11510)」や「コマンドインジェクションの脆弱性(CVE-2019-11539)」などは、実証コードを含む情報が公開されており、これら脆弱性を組み合わせることで遠隔の攻撃者から製品が動作する機器をroot権限にて乗っ取ることも可能という非常に大きなリスクとなっています。

最近の被害事例として、大手外貨両替サービスを提供するTravelex社がREvil(Sodinokibi)ランサムウェアに大規模感染した

VPN製品にもセキュリティ修正が含まれる最新のアップデートを適用するための組織ポリシーが不可欠です。
しかしながら、VPN製品へのアップデート適用は、多くの場合クライアントソフトウェアのアップデートなどが伴うことで利用者への負担が大きくなったり、製品ベンダーからのアップデート提供が遅れ、いわゆる0day脆弱性の期間が発生する可能性もないとは言えません。

即時のアップデート適用が難しい場合には、製品ベンダーが提供しているワークアラウンド(緩和策)があればそれを実施したり、IPSや次世代ファイアウォールなどのセキュリティ製品を予めネットワーク内に組み込んでおくことで脆弱性を突く攻撃を検知・防御できる可能性があるため、これらをアップデート適用までの暫定対処として実施いただくことを強く推奨します。


Feb 24, 2020

setup SSL VPN Client for Sophos UTM

概要

(1)ネットワーク定義、ユーザ定義の後、
(2)ユーザ向けポータル機能を有効にして、
(3)当該ユーザとしてログインし、
(4)ovpnファイルをダウンロード。
(5)デバイス側でのセットアップを行う。

注、上記(2),(3)を面倒がって、管理者でpemファイルを取得しても成功しない。
 (1)の後は、そこさえ気を付ければ難しくないです。

参考にしたところ

Sophos UTM: Remote Access via SSL and VPN - Configuration Guides
https://community.sophos.com/kb/en-us/116038
ここにあるマニュアルを参照すれば良い(↓)

Remote Access via SSL (UTM 9, English)
http://www.sophos.com/en-us/medialibrary/PDFs/documentation/utm90_Remote_Access_Via_SSL_geng.pdf

Setup a Sophos UTM SSL VPN In 7 Simple Steps!
https://www.fastvue.co/sophos/blog/sophos-utm-ssl-vpn-setup-guide/
本家サイトよりこちらの方がPDFを開く必要がなく、手軽かも。
細かい手順は、手元と一致しなかった(下記、例)が、ハマるような難度でもないです。
(例、アンドロイド用に「インストール」しようとしても、ovpnファイルダウンロードのみしか行われない..等)

Feb 22, 2020

記事いろいろ、VPN hack, http-methods, enum4linux, cudahushcat

Fox Kitten Campaign (2020.02)

Widespread Iranian Espionage-Offensive Campaign

サマリー (02/16)
https://www.clearskysec.com/fox-kitten/

フルレポート
https://www.clearskysec.com/wp-content/uploads/2020/02/ClearSky-Fox-Kitten-Campaign.pdf


Iranian hackers have been hacking VPN servers to plant backdoors in companies around the world (02/16)

https://www.zdnet.com/article/iranian-hackers-have-been-hacking-vpn-servers-to-plant-backdoors-in-companies-around-the-world/
Pulse Secure、Palo Alto Networks、Fortinet、Citrixの企業VPNサーバ等へのハックについて。

イラン政府支援ハッキングユニットは「IT、通信、石油およびガス、航空、政府、およびセキュリティの各セクターの企業」を標的に。実力はロシア、中国、北朝鮮などと並びうる。

本APTグルーブは1-day vulnerabilityの悪用能力や、カスタマイズドマルウェア開発能力がある。2019年、Pulse Secure「Connect」VPN(CVE-2019-11510)、Fortinet FortiOS VPN(CVE-2018-13379)、およびPalo Alto Networksの「Global Protect」で開示された脆弱性を迅速に武器化した。後にCitrix "ADC" VPNで公開された脆弱性であるCVE-2019-19781も。
。。。だそうです。


Iranian Hackers Exploiting VPN Flaws to Backdoor Organizations Worldwide (02/18)

https://thehackernews.com/2020/02/iranian-hackers-vpn-vulnerabilities.html

最初の足場を獲得すると、C2サーバーと通信して、バックドアを植えるために使用できる一連のカスタムVBScriptファイルをダウンロードする

さらに、ウイルス対策ソフトウェアによる検出を回避するために、バックドアコード自体をチャンクでダウンロードする。これらの個々のファイルをつなぎ合わせて実行可能ファイルを作成するのは、「combine.bat」。

これらのタスクを実行して持続性を実現するために、Juicy PotatoやInvoke the Hashなどのツールを悪用して、高レベルの特権を獲得し、ネットワークを横切って移動する。

攻撃者が開発した他のツールには次のものがある。
・STSRCheck-ターゲットネットワークのデータベース、サーバー、および開いているポートをマッピングし、デフォルトの資格情報でログ記録することでブルートフォースするツール。
・Port.exe-定義済みのポートとサーバーをスキャンするツール。

攻撃者がlateral movement能力を獲得すると、攻撃者は最終段階に移動します:関連情報について、侵害されたシステムをスキャンし、(POWSSHNETと呼ばれる自己開発ツールを使用して)リモートデスクトップ接続を確立して、またはハードコードされたIPアドレスへのソケットベースの接続を開いて、ファイルを盗み出します。
The Hacker News はCVEへのリンクなど、使いやすい印象。

http-methods

https://nmap.org/nsedoc/scripts/http-methods.html
nmapのスクリプトでのhttp-methodsの検出について

enum4linux Package Description

https://tools.kali.org/information-gathering/enum4linux
Windows やSambaの概況調査ツール。
以前は www.bindview.comで enum.exeで同様の事が出来たのだそうだ。

Kali Linux 1.0.4リリースとenum4linux

https://ozuma.hatenablog.jp/entry/20130730/1375196315
enum4linuxの続き。Perlとのこと。

cudahashcat

https://books.google.co.jp/books?id=6XS3DwAAQBAJ&pg=PA298&lpg=PA298&dq=cudahashcat&source=bl&ots=2YKMJ-Expf&sig=ACfU3U0E6vl6xX8LmFP8eWNUda353EFAfQ&hl=ja&sa=X&ved=2ahUKEwjLv-GcgtvnAhUVzmEKHetdDqU4FBDoATACegQICRAB

Amazon EC2のGPUインスタンスでハッシュ解読をやってみる (2016-05-20)

http://inaz2.hatenablog.com/entry/2016/05/20/011353

Aug 30, 2019

Black HatでのFortigate SSL VPN破りの記事

ハッカーは、広く使用されている2つのVPNからパスワードを積極的に盗もうとしています (08/24)
https://translate.google.com/translate?hl=ja&sl=en&u=https://arstechnica.com/information-technology/2019/08/hackers-are-actively-trying-to-steal-passwords-from-two-widely-used-vpns/
『パッチを適用していないサーバーに特別な文字列を含むWebリクエストを送信することで脆弱性を悪用できる・・・認証前のファイル読み取りの脆弱性は、約480,000台のサーバーにインストールされたFortigate SSL VPNと、約50,000台のマシンにインストールされた競合のPulse Secure SSL VPNに存在・・・
Devcoreの研究者は、両方の製品に他の重大な脆弱性を発見・・・攻撃者はとりわけ、悪意のあるコードをリモートで実行し、パスワードを変更することができます。
この脆弱性は、インターネットにアクセスする必要があり、組織のネットワークの非常に機密性の高い部分へのゲートウェイとして機能するソフトウェアに影響を与えるため、深刻です。 ハッシュ化された、場合によってはプレーンテキストのパスワード、暗号化キー、およびその他の機密データを取得すると、人々がそれらのネットワークに侵入する可能性があります。 より多くの作業を行うと、パッチ未適用のサーバーを特定する攻撃者は、Devcoreの研究者が発見した他の脆弱性も悪用する可能性があります。 Fortigateの1つの欠陥は、 「The Magic Backdoor」と呼ばれ、ハードコードされたキーを知っているリモートの攻撃者がパスワードを変更できるようにします。
フォーティネットとPulse Secureの両方の代表は、企業はできるだけ早くシステムにパッチを適用するよう顧客に何ヶ月も促していると述べた・・・これらのVPNのいずれかを使用している組織は、脆弱性がないことを確認するために今すぐ時間をかける必要があります。』

・SSL VPNを攻撃する-パート2:Fortigate SSL VPNを破る
https://translate.googleusercontent.com/translate_c?depth=1&hl=ja&rurl=translate.google.com&sl=en&sp=nmt4&u=https://devco.re/blog/2019/08/09/attacking-ssl-vpn-part-2-breaking-the-Fortigate-ssl-vpn/&xid=17259,15700002,15700021,15700186,15700190,15700256,15700259,15700262,15700265&usg=ALkJrhjNfsQgONsEUrtxhdyG3sFG2Yp9oQ
当該システムのWebサーバについては『WebサーバーがApacheから変更されたことがわかりましたが、それは2002年のApacheです』なので問題山積と想像できる。
アタックベクターを絞っていくための候補:
 ・CVE-2018-13379 :認証前の任意のファイル読取
 ・CVE-2018-13380 :認証前のXSS
 ・CVE-2018-13381 :認証前のヒープオーバーフロー
 ・CVE-2018-13382 :マジックバックドア
 ・CVE-2018-13383 :認証後のヒープオーバーフロー

この中から、CVE-2018-13381で攻めるも立ち往生。CVE-2018-13379 + CVE-2018-13383に軌道変更して成功するまでの紹介記事。
YouTubeでのデモも見られる。 
CVE-2018-13379については、fortigate migadmin/lang json で検索して出てくる、
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=13&cad=rja&uact=8&ved=2ahUKEwi_tdXHkJ7kAhV1yIsBHUtSDTQ4ChAWMAJ6BAgFEAE&url=https%3A%2F%2Fhackmd.io%2F%40HITCON%2F2019-cmt-note&usg=AOvVaw2kcUPdDsZ_BFIVrZDMeVGIとか、CVE-2018-13379 のexp.py も気になってる

Oct 25, 2018

FortiGate、POODLE FAQ、徳丸浩氏が明かす“セキュリティ人材不足”の解決策、CSIRT ほか

POODLEに関するFAQ (2014/10/16)
『これは深刻な脆弱性・・・中略・・・と言えるでしょう
・・・中略・・・
フォーティネットの製品に関してですが、FortiGateFortiMailはデフォルトの構成では脆弱な状態ですが、SSLv3を無効化するCLI設定があります』

---> 2019.06.01追記、ここから
これか? ↓
・FortiGate 脆弱性対策 (2017/06/07)
 http://extstrg.asabiya.net/pukiwiki/index.php?FortiGate%20%C0%C8%BC%E5%C0%AD%C2%D0%BA%F6
『SSLv2、SSLv3、TLS1.0、TLS1.1の無効化 # config vpn ssl settings  (settings) # set sslv3 disable  (settings) # set sslv2 disable  (settings) # set tlsv1-0 disable  (settings) # set tlsv1-1 disable  (settings) # end 』
---> 2019.06.01追記、ここまで
--> 2020.03.02追記、ここから
SSLv3の脆弱性へのPOODLE攻撃は2014から知られ、
TLS1.0/1.1も主要ブラウザでサポート廃止に動いており
最近はTLS1.2 も危なくなり、TLS1.3が発表されました。
気付いたら早めの対処(バージョンアップや設定変更など)が吉ですね。

・Transport Layer Security
 https://ja.wikipedia.org/wiki/Transport_Layer_Security
 「2015年6月、RFC 7568によってSSL 3.0の使用は禁止された」

・SSL Version 2 and 3 Protocol Detection (update 2019/03/27)
 https://www.tenable.com/plugins/nessus/20007
Severity: HighRisk Factor: HighCVSS v2.0 Base Score: 7.1CVSS v3.0 Base Score: 7.5

・SSLv3 プロトコルに暗号化データを解読される脆弱性(POODLE 攻撃) (2014/10/16)
https://jvn.jp/vu/JVNVU98283300/
 飲食店や駅、空港など無料Wi-Fiの使える場所では、第三者が正規アクセスポイント(AP)に見せかけた偽APを設置するなどして、通信盗聴を試行が容易です。
 そして『暗号化された通信内容の一部を解読される可能性があります。』

・「Google Chrome」「Firefox」「Safari」もTLS 1.0/1.1のサポートを廃止へ (2018/10/16)
https://forest.watch.impress.co.jp/docs/news/1148101.html
「TLS(Transport Layer Security)」はインターネット通信を暗号化するプロトコルだが、初期バージョンの「TLS 1.0」や「TLS 1.1」はすでに設計が古く、もはや安全なプロトコルとは言えない。
--> 2020.03.02追記、ここまで

・徳丸浩氏が明かす“セキュリティ人材不足”の解決策、「実は答えは出ている」

・大成建設はいかにしてCSIRT運用を成功させたか

・統率が取れないクラウド導入がもたらすリスク