ぷららのTransix DS-Lite（IPv4 over IPv6）からのアクセスがヨーロッパ圏からのアクセス？
transix DS-Liteは、日本国内にあるかと。。。
IPアドレスで判断する愚。。。。
また、ぷららのサポートに問い合わせるのかな。。。。。
transix DS-Liteは、日本国内にあるかと。。。
IPアドレスで判断する愚。。。。
また、ぷららのサポートに問い合わせるのかな。。。。。
Intel Core i7の性能を調べている時に「AES-NI（AES-New Instructions）」と言うAES暗号化処理を支援する命令セットが使用出来る事を知った（2011年発売のCore i7-2600にも装備されいた。。。）。「Using Intel® AES New Instructions and PCLMULQDQ to Significantly Improve IPSec Performance on Linux」によると「AES-GCM」で400%高速化が実現したと。
strongSwan 5.3.1（2015年6月）から「aesni plugin（provides CBC, CTR, XCBC, CMAC, CCM and GCM crypto primitives for AES-128/192/256）」が提供されていた。
「macOS MojaveのIKEv2 IPsec VPN最大回線速度計測」で「aes256-cbc」のスループット688Mbps、「128aes-cbc」のスループット827Mbpsが計測された。
プラグインを確認すると「aesni」プラグインがロードされている。プラグインがロードされないように設定しても計測値が変わらない。IPSecのESPパケット暗号化は、カーネルで行われていてプラグインのロードと無関係に命令セットが使われているようだ。
「Macbook pro（macOS Mojave）」のIKEv2 VPNから「aes128-cbc」「aes256-cbc（default）」「aes128-gcm」「aes256-gcm」でスループットを計測確認してみた。
（１）macOS VPNアプリの設定
macOSのIKEv2 VPNアプリは、暗号化方式を選択できない。暗号化方式を指定して接続するには、構成プロファイル VPNペイロードで指定する必要がある。実際のプロファイルは、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」で利用したプロファイルを基にした。「IKE」は、変更せずに「ESP」の暗号化方式と認証方式だけを変更した。変更した構成プロファイルは、iOSにも利用できる。
--- 2019/9/10追記：GCM指定時に設定していた「Integirity」を未指定に変更。
（２）strongSwanの設定
GCMが選択できるように「esp=」にGCMを追加
---2019/9/10追記：GCM指定を変更
（３）計測
opensslで「Core i7-2600」の「AES-NI」が有効か確認処理速度をopensslで確認約5.9倍の処理速度で「AES-NI」が有効であることが確認できる。
AES128CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES128GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
結果
Core i5-8400の例だと「AES128CBC:1.28Gbps」「AES128GCM128: 2.59Gbps」のスループットが得られているようだが、「AES128-CBCとAES128GCM16」で、これほどの差は得られていない。ほぼ同等スループットなので、暗号化方式以外の処理が支配的で、Core i7-2600のCPU処理能力の結果であろうか。。。
--- 2019/9/10追記：GCM指定時に「Integrity」指定を削除したが、スループットに変化なし
strongSwan 5.3.1（2015年6月）から「aesni plugin（provides CBC, CTR, XCBC, CMAC, CCM and GCM crypto primitives for AES-128/192/256）」が提供されていた。
「macOS MojaveのIKEv2 IPsec VPN最大回線速度計測」で「aes256-cbc」のスループット688Mbps、「128aes-cbc」のスループット827Mbpsが計測された。
プラグインを確認すると「aesni」プラグインがロードされている。プラグインがロードされないように設定しても計測値が変わらない。IPSecのESPパケット暗号化は、カーネルで行われていてプラグインのロードと無関係に命令セットが使われているようだ。
「Macbook pro（macOS Mojave）」のIKEv2 VPNから「aes128-cbc」「aes256-cbc（default）」「aes128-gcm」「aes256-gcm」でスループットを計測確認してみた。
（１）macOS VPNアプリの設定
macOSのIKEv2 VPNアプリは、暗号化方式を選択できない。暗号化方式を指定して接続するには、構成プロファイル VPNペイロードで指定する必要がある。実際のプロファイルは、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」で利用したプロファイルを基にした。「IKE」は、変更せずに「ESP」の暗号化方式と認証方式だけを変更した。
AES-128-CBC
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-128</string>
<key>IntegrityAlgorithm</key>
<string>SHA1-96</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-256-CBC
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256</string>
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-128-GCM
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-128-GCM</string>
<key>IntegrityAlgorithm</key>
<string>SHA1-96</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
AES-256-GCM
<key>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>14</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256-GCM</string>
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
--- 2019/9/10追記：GCM指定時に設定していた「Integirity」を未指定に変更。
（２）strongSwanの設定
GCMが選択できるように「esp=」にGCMを追加
/etc/ipsec.conf
conn %default
keyexchange=ikev2
#for Windows10 IKEv2 VPN
ike=aes256-sha256-modp1024
#for GCM testing
esp=aes128gcm16-sha, aes256gcm16-sha256
auto=add
left=%any
leftauth=pubkey
leftsubnet=192.168.0.0/20,2409:10:XXXX:YY00::/56,2404:1a8::/32
#for iOS VPN apli
leftsendcert=always
leftcert=debian10-pub.pem
leftid=@vpn.AAAAAAAA.mydns.jp
right=%any
rightsourceip=192.168.15.0/24,2409:10:XXXX:YY30::15:0/120
rightdns=192.168.11.250,2409:10:XXXX:YY20::11:250（３）計測
opensslで「Core i7-2600」の「AES-NI」が有効か確認
root@debian10:~$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 36 bits physical, 48 bits virtual
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Model name: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Stepping: 7
CPU MHz: 1596.243
CPU max MHz: 3800.0000
CPU min MHz: 1600.0000
BogoMIPS: 6784.69
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 8192K
NUMA node0 CPU(s): 0-7
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb pti tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
openssl speed aes-256-cbc
OpenSSL 1.1.1c 28 May 2019
built on: Thu May 30 15:27:48 2019 UTC
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256 cbc 84293.98k 89436.65k 90589.10k 91029.16k 91187.88k 91247.96k
openssl speed -evp aes-256-cbc
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 393369.35k 491012.78k 523522.90k 532274.52k 534899.37k 535183.36k
AES128CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256CBC
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES128GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
AES256GCM16
/sbin/ipsec statusall 結果
iperf3スループット計測結果とmacOS cpu状況
結果
AES128-CBC 825Mbps AES256-CBC 682Mbps AES128GCM16 878Mbps AES256GCM16 824Mbps
Core i5-8400の例だと「AES128CBC:1.28Gbps」「AES128GCM128: 2.59Gbps」のスループットが得られているようだが、「AES128-CBCとAES128GCM16」で、これほどの差は得られていない。ほぼ同等スループットなので、暗号化方式以外の処理が支配的で、Core i7-2600のCPU処理能力の結果であろうか。。。
--- 2019/9/10追記：GCM指定時に「Integrity」指定を削除したが、スループットに変化なし
「NVR500 L2TP/IPsec VPN最大回線速度計測」で使用したMacbook proの能力を確認してみた。
Macbook pro（Late 2013 ）仕様
macOS Mojave 10.14.6
Core i7 - 4850HQ （2.3Ghz [3.5]）第4世代
IKEv2 IPsec サーバー（Dell XPS8300）
Debian 10 （Buster）
strongSwan 5.7.2
Core i7 - 2600（3.4Ghz [3.8]） 第2世代
確認したネットワーク構成は下記の通り
「NVR500 L2TP/IPsec VPN最大回線速度計測」と同様に、「192.168.1.0/24」のネットワークに「Debian10」を設置。Debian10は、「firmware-10.0.0-amd64-DVD-1.iso」で基本パッケージ+SSH+WEB + iperf3 + strongswan + libcharon-extra-plugins + resolvconf + dnsutils + net-toolsのルータ構成。ひかり電話HGWからDHCPでIPv4アドレス「192.168.1.57」を設定し、IPv6アドレスはstaticで「2409:10:XXXX:YY00::1:110」を設定した。このIPv6アドレスをドメイン名「vpn.AAAAAAAA.mydns.jp」でDDNSに登録。Debian10の二つ目のEthernetインターフェースにIPv4「192.168.14.1/24」、DHCPv6-PDで得たPrefix「2409:10:XXXX:YY30::/60」からIPv6「2409:10:XXXX:YY30::14:1/64」をそれぞれstatic設定した。
Debian10には、スループット計測用iperf3をサーバ起動させ計測した（手持ちPC不足のため）。
strongSWAN接続端末側の「riightsourceip」は、「192.168.15.0/24」「2409:10:XXXX:YY30::15:0/120」から設定されるよう設計した。
strongSwan設定は、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」と同様とした。
接続確認
macOS Mojave標準選択ESP暗号化方式
ESP暗号化方式指定「ike=aes128-sha!」
iperf3をIKEv2/IPsecサーバで動作させることによる影響確認
IKEv2/IPsecサーバ上でiperf3を二つ起動させる
iperf3 -s -D -B 192.168.1.57 --logfile iperf3-log-1-57.txt
iperf3 -s -D -B 192.168.14.1 --logfile iperf3-log-14-1.txt
コンソールから「iperf3 -c 192.168.14.1 -t 120」で同一サーバ上でのスループット計測をした場合としない場合でIKEv2/IPsec VPN接続と接続端末から「iperf3 -c 192.168.1.57 -t 60」でスループット計測を行い影響度を確認した。
IPv4 over IKEv2/IPsec over IPv6のMTUを確認
NGN経由のIPv6 IPoEのMTUは、1500。IKEv2/IPsecのMTUは、1406であるが、macOS MojaveのipsecインターフェースのMTUは、1400。
一応確認
接続端末（Macbook pro）からサーバ側へ「ping -s 1372 -c 3 192.168.14.1」（pingデータ長+IPv4(20)+TCP(8)=1400）まで応答がある事を確認
サーバ側からVPN端末へ「ping -s 1372 -c3 192.168.15.1」まで応答がある事を確認
IPv4 over IKEv2/IPsec over IPv6のスループットを計測
iperf3による影響調査比較スループット
iperf3x2は、計測用に加え並行してiperf3サーバとクライアントを実行（室温26℃）
macOS MojaveのIKEv2/IPsec VPNスループット計測値（室温24℃）
AES256-SHA256計測データ
AES128-SHA1計測データ
計測結果
AHS256-SHA256: 688Mbps（macOS Mojave標準）
AHS128-SHA1: 827Mbps
下記サイトのIPsecスループット計測では、「AHS128-SHA1」で
「Core i5-7200UのIPsecスループット」が0.93Gbps
「Core i5-7500TのIPsecスループット」が1.11Gbps
「Core i5-8400のIPsecスループット」が1.28Gbps
「Core i7-8700TのIPsecスループット」が1.58Gbps
と計測されている。
CPU毎のCinebench R15/sigle core値を調べてみた。
ベンチマーク値は、「CPU-Monkey」の計測値をリストした。「Core i7-2600」がリストにないが、「Core i7 2600K」のベンチマーク値を記載した（GPUが異なる）。CPUの仕様は、「インテルCore Xシリーズ・プロセッサー・ファミリー」から抽出した。
これらの事からスループット計測に使用した「Core i7-2600」の能力がMacbook proの「Core i7-4850HQ」より若干低く、サーバー側のCPU能力を上げることで「Core i5-7200U」程度のIPsecスループット値計測が推察できる。
Macbook pro（Late 2013 ）仕様
macOS Mojave 10.14.6
Core i7 - 4850HQ （2.3Ghz [3.5]）第4世代
IKEv2 IPsec サーバー（Dell XPS8300）
Debian 10 （Buster）
strongSwan 5.7.2
Core i7 - 2600（3.4Ghz [3.8]） 第2世代
確認したネットワーク構成は下記の通り
「NVR500 L2TP/IPsec VPN最大回線速度計測」と同様に、「192.168.1.0/24」のネットワークに「Debian10」を設置。Debian10は、「firmware-10.0.0-amd64-DVD-1.iso」で基本パッケージ+SSH+WEB + iperf3 + strongswan + libcharon-extra-plugins + resolvconf + dnsutils + net-toolsのルータ構成。ひかり電話HGWからDHCPでIPv4アドレス「192.168.1.57」を設定し、IPv6アドレスはstaticで「2409:10:XXXX:YY00::1:110」を設定した。このIPv6アドレスをドメイン名「vpn.AAAAAAAA.mydns.jp」でDDNSに登録。Debian10の二つ目のEthernetインターフェースにIPv4「192.168.14.1/24」、DHCPv6-PDで得たPrefix「2409:10:XXXX:YY30::/60」からIPv6「2409:10:XXXX:YY30::14:1/64」をそれぞれstatic設定した。
Debian10には、スループット計測用iperf3をサーバ起動させ計測した（手持ちPC不足のため）。
strongSWAN接続端末側の「riightsourceip」は、「192.168.15.0/24」「2409:10:XXXX:YY30::15:0/120」から設定されるよう設計した。
strongSwan設定は、「Buffalo OpenWrt化WZR-HP-G300NHでIKEv2 VPN over ぷららIPv6 IPoE接続」と同様とした。
/etc/ipsec.conf
config setup
# strictcrlpolicy=yes
# uniqueids = no
# charondebug="cfg 2,ike 2,esp 2"
conn %default
keyexchange=ikev2
#for Windows10 IKEv2 VPN
ike=aes256-sha256-modp1024
# esp=aes128-sha!
auto=add
left=%any
leftauth=pubkey
leftsubnet=192.168.0.0/20,2409:10:XXXX:YY00::/56,2404:1a8::/32
#for iOS VPN apli
leftsendcert=always
leftcert=debian10-pub.pem
leftid=@vpn.AAAAAAAA.mydns.jp
right=%any
rightsourceip=192.168.15.0/24,2409:10:XXXX:YY30::15:0/120
rightdns=192.168.11.250,2409:10:XXXX:YY10::11:250
conn eap-id-passwd
rightauth=eap-mschapv2
eap_identity=%any/etc/ipse.secrets
: RSA debian10-key.pem "key password"
user1 : EAP "user password"
/etc/strongswan.conf
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
#for iOS/OSX IKEv2 VPN apli
attr {
25 = familyname,flets-east.jp
}
}
}
include strongswan.d/*.conf接続確認
macOS Mojave標準選択ESP暗号化方式
ESP暗号化方式指定「ike=aes128-sha!」
iperf3をIKEv2/IPsecサーバで動作させることによる影響確認
IKEv2/IPsecサーバ上でiperf3を二つ起動させる
iperf3 -s -D -B 192.168.1.57 --logfile iperf3-log-1-57.txt
iperf3 -s -D -B 192.168.14.1 --logfile iperf3-log-14-1.txt
コンソールから「iperf3 -c 192.168.14.1 -t 120」で同一サーバ上でのスループット計測をした場合としない場合でIKEv2/IPsec VPN接続と接続端末から「iperf3 -c 192.168.1.57 -t 60」でスループット計測を行い影響度を確認した。
IPv4 over IKEv2/IPsec over IPv6のMTUを確認
NGN経由のIPv6 IPoEのMTUは、1500。IKEv2/IPsecのMTUは、1406であるが、macOS MojaveのipsecインターフェースのMTUは、1400。
一応確認
接続端末（Macbook pro）からサーバ側へ「ping -s 1372 -c 3 192.168.14.1」（pingデータ長+IPv4(20)+TCP(8)=1400）まで応答がある事を確認
サーバ側からVPN端末へ「ping -s 1372 -c3 192.168.15.1」まで応答がある事を確認
IPv4 over IKEv2/IPsec over IPv6のスループットを計測
iperf3による影響調査比較スループット
iperf3x2は、計測用に加え並行してiperf3サーバとクライアントを実行（室温26℃）
macOS MojaveのIKEv2/IPsec VPNスループット計測値（室温24℃）
AES256-SHA256計測データ
AES128-SHA1計測データ
計測結果
AHS256-SHA256: 688Mbps（macOS Mojave標準）
AHS128-SHA1: 827Mbps
下記サイトのIPsecスループット計測では、「AHS128-SHA1」で
「Core i5-7200UのIPsecスループット」が0.93Gbps
「Core i5-7500TのIPsecスループット」が1.11Gbps
「Core i5-8400のIPsecスループット」が1.28Gbps
「Core i7-8700TのIPsecスループット」が1.58Gbps
と計測されている。
CPU毎のCinebench R15/sigle core値を調べてみた。
ベンチマーク値は、「CPU-Monkey」の計測値をリストした。「Core i7-2600」がリストにないが、「Core i7 2600K」のベンチマーク値を記載した（GPUが異なる）。CPUの仕様は、「インテルCore Xシリーズ・プロセッサー・ファミリー」から抽出した。
これらの事からスループット計測に使用した「Core i7-2600」の能力がMacbook proの「Core i7-4850HQ」より若干低く、サーバー側のCPU能力を上げることで「Core i5-7200U」程度のIPsecスループット値計測が推察できる。
スポット的に「ぷらら V6エクスプレス（Transix + DS-Lite）の回線速度」を確認した。
時間帯を含め数日間のTransix DS-Lite（IPv4）速度を確認してみた。
フレッツ 光ネクスト ファミリー・ハイスピード（下り最大200Mbps/上り最大100Mbps）
ぷらら V6エクスプレス（Transix / DS-Lite）GBT-Wire接続
2019年7月11日16時55分-7月14日10時30分（5分間隔）
計測タイミングによりping応答が（最大380msec）遅かったりしたが、特に夜間帯有意な遅さではなかった。また、下り速度、上り速度との相関も観られなかった。中央値（メディアン）でping応答6.9msec、下り速度227Mbps、上り速度94Mbps。
ぷらら V6エクスプレス（Transix / DS-Lite）の測定であるが、「Internet Multifeed」の「Transix DS-Lite」利用のISPであれば、同じAFTERを利用する事になる。ギガファミリー、ファミリー・ハイスピード、ファミリーでサービス毎の最大速度制限が設定されているようだ。（2019/7/15追記）ISP毎にインターネット接続速度制限があるとの「情報」or 「噂」があるが未確認。
計測は、ここ「LinuxでもSpeedtestがしたい」を参考に「speedtest-cli」（Python）を使い、「Synology DS-216Jのタスクスケデューラ」で実施した。
DS-216Jでは、「rev」コマンドが実装されていないので「sed」を使い、下記のコマンドを「タスク スケデューラ」の「ユーザ指定のスクリプト」に設定して実行した。
時間帯を含め数日間のTransix DS-Lite（IPv4）速度を確認してみた。
フレッツ 光ネクスト ファミリー・ハイスピード（下り最大200Mbps/上り最大100Mbps）
ぷらら V6エクスプレス（Transix / DS-Lite）GBT-Wire接続
2019年7月11日16時55分-7月14日10時30分（5分間隔）
計測タイミングによりping応答が（最大380msec）遅かったりしたが、特に夜間帯有意な遅さではなかった。また、下り速度、上り速度との相関も観られなかった。中央値（メディアン）でping応答6.9msec、下り速度227Mbps、上り速度94Mbps。
ぷらら V6エクスプレス（Transix / DS-Lite）の測定であるが、「Internet Multifeed」の「Transix DS-Lite」利用のISPであれば、同じAFTERを利用する事になる。ギガファミリー、ファミリー・ハイスピード、ファミリーでサービス毎の最大速度制限が設定されているようだ。（2019/7/15追記）ISP毎にインターネット接続速度制限があるとの「情報」or 「噂」があるが未確認。
計測は、ここ「LinuxでもSpeedtestがしたい」を参考に「speedtest-cli」（Python）を使い、「Synology DS-216Jのタスクスケデューラ」で実施した。
DS-216Jでは、「rev」コマンドが実装されていないので「sed」を使い、下記のコマンドを「タスク スケデューラ」の「ユーザ指定のスクリプト」に設定して実行した。
/bin/python /volume1/homes/admin/speedtest-cli --list | /bin/grep "OPEN Project" | /bin/sed -E "s/([:digit:]*)\).*$/\1/g" | /bin/xargs -I % /bin/python /volume1/homes/admin/speedtest-cli --server % --csv >> /volume1/homes/admin/speedtest.csv
「ぷらら」メールサーバがTransix DS-Liteからの特定ポートアクセスをblockingしていた。「ぷらら」サポートセンタとのやり取りで、「スパムメール対策」が関係するかもしれないので「メール接続認証」を確認するように言われた。それ以前の「接続」問題だったのだがopensslを使って接続できる「465ポート」で「認証」と「メール送信」を行い、Wiresharkでパケット確認をしてみた。ポートブロック解除後にポート587にstartTLSでSMTP送信のパケットキャプチャ確認もしてみた。
（１）「認証用」データを作る
「ユーザID」（ぷららはメールアドレス）と「パスワード」からSMTP認証を参考に認証用データを作る（macOS Mojave）。
接続時に使用するのでコピーしておく（macOSでは、「pbcopy」でクリップボードにコピーされる）。
（２）「openssl s_client」でメールサーバに接続し、SMTP認証を行う
「Authentication successful」で認証されたことが確認できる。
（３）Wiresharkでメールサーバへの接続をパケットキャプチャする
wiresharkでキャプチャすると465(SSL)なのでSSL接続後のデータが暗号化されている
（４）openssl s_clientで接続時の復号鍵を取り出す
Wiresharkのwiki（TLS Decryption)では、「RSA private key」（ Diffie-Hellman [DH] 鍵交換方式が主流になってきているので暗号方式を限定して接続しないと復号できない）か「Key log file」（logに記録されるPre-Master-SecretとClientHello MessagesのClient RandomからMaster-Secretを算出する） を使ってSSL/TLSパケット復号が解説されている。詳細解説。opensslの接続ログで「Session-ID」と「Master-Key」が記録されるが、「Session-ID」は使えないようだ。2011年の記事なので「RSA Session-ID:xxxx Master-Key:yyyy」で確認してみたが復号されない。
「openssl」のバージョン1.1.1以降では、ログに鍵を記録するcallbackが用意されているらしい。version 1.1.1c（28 May 2019）では、s_clientに「-keylogfile」オプションがあり、ファイルを指定すると「CLIENT_RANDOM書式」の鍵が記録される。ファイルは、接続毎に鍵が追記されて行く。macOS Mojaveでは、「LibreSSL 2.6.5」（openssl 1.0.1APIと1.0.2APIの一部）が実装されている。LibreSSLでcallbackが実装されているかは不明。「openssl s_client」には、「-keylogfile」オプションも無いし、「SSLKEYLOGFILE」も機能していないようだ。
「openssl s_client」のオプション「-msg」指定で、「Client/Server Hello」パラメータと「Master-Key」が出力されるので「CLIENT_RANDOM zzzz yyyy」形式の鍵情報を取り出すことができる。下記は、SMTPのstartTLS接続で「smtp.log」にログを記録している。
「smtp.log」のClientHelloデータ
ClientHello識別子+24bitメッセージ長+プロトコルバージョン+（32bit gmt unix time + 28bytes乱数）。7バイト目から38バイト目までがClientHelloのRandom値
でRandom値を取り出す。
「Master-Key」を取り出す。「Session-ID」も取り出してみる。
Wiresharkの「Preference-Protocol-SSL」の「(Pre)Master-Secret log filename」の書式で書き出す
「one-liner」でClient/ServerのRandom値を取出すスクリプト。CLIENT_RANDOM書式でClientHelloのRandom値だけ出力させてみた。
「smtp-random-key.log」を「（Pre）Master-Secret log filename」に指定して復号。
SMTPプロトコルが表示される
（５）secure.plala.or.jp:587 startTLSでメール送信とパケットキャプチャ
「WIreshark」を起動しキャプチャ状態で「openssl s_client」を実行
「Wireshark」のキャプチャを停止し、鍵ファイルを作成する。
SMTP認証とSMTPメール送信が復号されキャプチャデータとして表示される
受信したメール（ぷららメールサーバからぷららメールサーバへopenssl s_clientで）
（１）「認証用」データを作る
「ユーザID」（ぷららはメールアドレス）と「パスワード」からSMTP認証を参考に認証用データを作る（macOS Mojave）。
printf "%s\0%s\0%s" someone@any.plala.or.jp someone@any.plala.or.jp PASSWORD | base64 | tr -d '\n' | pbcopy接続時に使用するのでコピーしておく（macOSでは、「pbcopy」でクリップボードにコピーされる）。
（２）「openssl s_client」でメールサーバに接続し、SMTP認証を行う
echo -e "auth plain c29tZW9uZUBhbnkucGxhbGEub3IuanAAc29tZW9uZUBhbnkucGxhbGEub3IuanAAUEFTU1dPUkQ=\nquit" | openssl s_client -quiet -crlf -connect secure.plala.or.jp:465 2> /dev/null
220 msc11.plala.or.jp ESMTP server ready Mon, 17 Jun 2019 17:25:49 +0900
235 Authentication successful
221 msc11.plala.or.jp ESMTP server closing connection「Authentication successful」で認証されたことが確認できる。
（３）Wiresharkでメールサーバへの接続をパケットキャプチャする
echo -e "ehlo\nquit" | openssl s_client -connect secure.plala.or.jp:465 -quiet -crlf 2>/dev/null
220 msc12.plala.or.jp ESMTP server ready Sun, 23 Jun 2019 11:29:10 +0900
250-msc12.plala.or.jp
250-AUTH=LOGIN PLAIN CRAM-MD5
250-AUTH LOGIN PLAIN CRAM-MD5
250-PIPELINING
250-DSN
250-8BITMIME
250 SIZE 20971520
221 msc12.plala.or.jp ESMTP server closing connectionwiresharkでキャプチャすると465(SSL)なのでSSL接続後のデータが暗号化されている
（４）openssl s_clientで接続時の復号鍵を取り出す
Wiresharkのwiki（TLS Decryption)では、「RSA private key」（ Diffie-Hellman [DH] 鍵交換方式が主流になってきているので暗号方式を限定して接続しないと復号できない）か「Key log file」（logに記録されるPre-Master-SecretとClientHello MessagesのClient RandomからMaster-Secretを算出する） を使ってSSL/TLSパケット復号が解説されている。詳細解説。opensslの接続ログで「Session-ID」と「Master-Key」が記録されるが、「Session-ID」は使えないようだ。2011年の記事なので「RSA Session-ID:xxxx Master-Key:yyyy」で確認してみたが復号されない。
「openssl」のバージョン1.1.1以降では、ログに鍵を記録するcallbackが用意されているらしい。version 1.1.1c（28 May 2019）では、s_clientに「-keylogfile」オプションがあり、ファイルを指定すると「CLIENT_RANDOM書式」の鍵が記録される。ファイルは、接続毎に鍵が追記されて行く。macOS Mojaveでは、「LibreSSL 2.6.5」（openssl 1.0.1APIと1.0.2APIの一部）が実装されている。LibreSSLでcallbackが実装されているかは不明。「openssl s_client」には、「-keylogfile」オプションも無いし、「SSLKEYLOGFILE」も機能していないようだ。
「openssl s_client」のオプション「-msg」指定で、「Client/Server Hello」パラメータと「Master-Key」が出力されるので「CLIENT_RANDOM zzzz yyyy」形式の鍵情報を取り出すことができる。下記は、SMTPのstartTLS接続で「smtp.log」にログを記録している。
echo -e "ehlo\nquit" | openssl s_client -connect secure.plala.or.jp:465 -quiet -crlf -msg 2>/dev/null > smtp.logClientHello識別子+24bitメッセージ長+プロトコルバージョン+（32bit gmt unix time + 28bytes乱数）。7バイト目から38バイト目までがClientHelloのRandom値
cat smtp.log | grep -A 3 -e "ClientHello" | sed '1d' | tr '\n' ' ' | sed 's/ //g' | sed -e 's/^.\{12\}\(.\{64\}\).*$/\1/g'9420cdb22e9988f8a1e95918182a60d646622553e337e15d1fdcb4d991d91d7ecat smtp.log | grep -e "Master-Key:" | sed -e 's/^.*Master-Key: \(.*\)$/\1/g'F82000D96468E651DA48D98D30339F83BA8841CA8D15470A829AC89ED5E6218AC9BD73CD7396CC91B51A87136346A5EFcat smtp.log | grep -e "Session-ID:" | sed -e 's/^.*Session-ID: \(.*\)$/\1/g'C4C84A1A82C0858DBD58C5985362256745E9908B257171CFB5AA4A8778946C30Wiresharkの「Preference-Protocol-SSL」の「(Pre)Master-Secret log filename」の書式で書き出す
--- pick-ssl-keys.sh ---
#!/bin/bash
fl1="smtp.log"
okf1="smtp-random-key.log"
okf2="smtp-session-key.log"
krand=`cat $fl1 | grep -A 3 -e "ClientHello" | sed '1d' | tr '\n' ' ' | sed 's/ //g' | sed -e 's/^.\{12\}\(.\{64\}\).*$/\1/g'`
ksess=`cat $fl1 | grep -e "Master-Key:" | sed -e 's/^.*Master-Key: \(.*\)$/\1/g'`
isess=`cat $fl1 | grep -e "Session-ID:" | sed -e 's/^.*Session-ID: \(.*\)$/\1/g'`
echo "CLIENT_RANDOM $krand $ksess" > $okf1
echo "RSA Session-ID:$isess Master-Key:$ksess" > $okf2
echo "CLIENT_RANDOM $krand $ksess"
echo "RSA Session-ID:$isess Master-Key:$ksess"CLIENT_RANDOM 9420cdb22e9988f8a1e95918182a60d646622553e337e15d1fdcb4d991d91d7e F82000D96468E651DA48D98D30339F83BA8841CA8D15470A829AC89ED5E6218AC9BD73CD7396CC91B51A87136346A5EF
RSA Session-ID:C4C84A1A82C0858DBD58C5985362256745E9908B257171CFB5AA4A8778946C30 Master-Key:F82000D96468E651DA48D98D30339F83BA8841CA8D15470A829AC89ED5E6218AC9BD73CD7396CC91B51A87136346A5EF$ ls smtp-*.logsmtp-random-key.log smtp-session-key.log「one-liner」でClient/ServerのRandom値を取出すスクリプト。CLIENT_RANDOM書式でClientHelloのRandom値だけ出力させてみた。
cat smtp.log | awk '/Master-Key:/{key=$2} {b=1;e=16;if(l==3)b=7;if(l==1)e=6;for(i=b;i<=e;i++)s=s$i;if(l--==1)r[s]=1}/ ClientHello$/{l=3;s=""} END{for(rnd in r)print "CLIENT_RANDOM",rnd,key}'CLIENT_RANDOM 9420cdb22e9988f8a1e95918182a60d646622553e337e15d1fdcb4d991d91d7e F82000D96468E651DA48D98D30339F83BA8841CA8D15470A829AC89ED5E6218AC9BD73CD7396CC91B51A87136346A5EF「smtp-random-key.log」を「（Pre）Master-Secret log filename」に指定して復号。
SMTPプロトコルが表示される
（５）secure.plala.or.jp:587 startTLSでメール送信とパケットキャプチャ
「WIreshark」を起動しキャプチャ状態で「openssl s_client」を実行
echo -e "auth plain c29tZW9uZUBhbnkucGxhbGEub3IuanAAc29tZW9uZUBhbnkucGxhbGEub3IuanAAUEFTU1dPUkQ=\nmail from: someone@any.plala.or.jp\nrcpt to: xxxxxxxx@yyyyy.plala.or.jp\ndata\nsubject: testing\ntesting mail body\n.\nquit" | openssl s_client -quiet -crlf -connect secure.plala.or.jp:587 -starttls smtp -msg 2>/dev/null > smtp.log$./pick-ssl-keys.shCLIENT_RANDOM a15c8dc12b2abb53443c1ec7e1b7006bb9de23dff19413a8b8f0971d1b7903b8 A9AB2E5EE5DE555C424AC90A2D16E912C6B8C6476BD013CE3BEF0625FDB1B9BFA870EAAD3668064178C20AB73FA7CFE4
RSA Session-ID:74F21376499E738F1B87CB2B78999040E06D93E005426283939C43016FF6293C Master-Key:A9AB2E5EE5DE555C424AC90A2D16E912C6B8C6476BD013CE3BEF0625FDB1B9BFA870EAAD3668064178C20AB73FA7CFE4
「Preference-Protocol-SSL」の「（Pre）Master-Secret log filename」に「smtp-random-key.log」を指定する。指定されたログファイルに作成したデータをマージしても良い（複数のCLIENT_RANDOM）。RSA Session-ID:74F21376499E738F1B87CB2B78999040E06D93E005426283939C43016FF6293C Master-Key:A9AB2E5EE5DE555C424AC90A2D16E912C6B8C6476BD013CE3BEF0625FDB1B9BFA870EAAD3668064178C20AB73FA7CFE4
SMTP認証とSMTPメール送信が復号されキャプチャデータとして表示される
受信したメール（ぷららメールサーバからぷららメールサーバへopenssl s_clientで）
アクセス
トータル
