netstatには残っているが、TCPとしてはFINパケットが送り終わった状態ってあるのかなの実験

考察１

javaで作ったFTPコマンドでサーバ側にputした

①tcpdumpデータからの考察

クライアント側：192.168.3.2.59335
サーバ側：192.168.3.150.ftp

 

9:25:24.403650 IP 192.168.3.150.ftp-data > 192.168.3.2.59336: Flags [.], ack 1, win 115, options [nop,nop,TS val 542169 ecr 1520073], length 0
19:25:24.403863 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 129:151, ack 83, win 115, length 22
19:25:24.406881 IP 192.168.3.2.59336 > 192.168.3.150.ftp-data: Flags [P.], seq 1:12, ack 1, win 260, options [nop,nop,TS val 1520073 ecr 542169], length 11
19:25:24.406892 IP 192.168.3.2.59336 > 192.168.3.150.ftp-data: Flags [F.], seq 12, ack 1, win 260, options [nop,nop,TS val 1520073 ecr 542169], length 0
19:25:24.406998 IP 192.168.3.150.ftp-data > 192.168.3.2.59336: Flags [.], ack 12, win 115, options [nop,nop,TS val 542172 ecr 1520073], length 0
19:25:24.407099 IP 192.168.3.150.ftp-data > 192.168.3.2.59336: Flags [F.], seq 1, ack 13, win 115, options [nop,nop,TS val 542172 ecr 1520073], length 0
19:25:24.407701 IP 192.168.3.2.59336 > 192.168.3.150.ftp-data: Flags [.], ack 2, win 260, options [nop,nop,TS val 1520074 ecr 542172], length 0
19:25:24.408014 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 151:175, ack 83, win 115, length 24
19:25:24.408565 IP 192.168.3.2.59335 > 192.168.3.150.ftp: Flags [.], ack 175, win 255, length 0
19:25:24.410196 IP 192.168.3.2.59335 > 192.168.3.150.ftp: Flags [F.], seq 83, ack 175, win 255, length 0
19:25:24.410406 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 175:185, ack 84, win 115, length 10
19:25:24.410439 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 185:215, ack 84, win 115, length 30
19:25:24.410470 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 215:217, ack 84, win 115, length 2
19:25:24.411142 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 217:227, ack 84, win 115, length 10
19:25:24.411167 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 227:244, ack 84, win 115, length 17
19:25:24.411183 IP 192.168.3.150.ftp > 192.168.3.2.59335: Flags [P.], seq 244:246, ack 84, win 115, length 2
19:25:24.411222 IP 192.168.3.2.59335 > 192.168.3.150.ftp: Flags [R.], seq 84, ack 185, win 0, length 0

■■■■考察結果■■■■

データポート（ftp-data）に関しては、サーバ側からFのフラグをクライアントに投げているのがわかる。

一方、制御ポート（ftp）に関しては、クライアント側からFフラグを投げ、回答がなかったのかRフラグ（強制終了）を投げている。

netstatからも同様に通信があることさえ見えなかった。。。。

■■■■疑問■■■■


そもそもnetstatはLinuxのどの内容を表示しているのか。。。

 

WAS間の証明書の考え方

WASのデプロイメントマネジャーとノードエージェント間通信もSSL通信が可能。

WAS7.0からチェーン証明書というWASのルート証明書によって
署名を行う証明書として使用する事ができるようになった。


WASがSSLに使用する証明書は、鍵ストア（ファイル名：key.p12）と、トラストストア（ファイル名：trust.p12）に保管されます。
それぞれ、鍵ストア (key.p12) には、個人証明書 (Personal Certificate) が含まれ、
トラストストア (trust.p12) には、署名者証明書 (Signer Certificate) すなわち公開鍵が含まれます。

証明書に関して

そもそも証明書とは

証明書は、Webサイトの運営者が自身の発行先情報を認証局に送付し証明書の発行を依頼します。

⇒認証局から発行されたものが通常の証明書

証明書は、X.509という仕様に基づいており、どのような証明書もこのX.509の仕様に従って発行されています。
Webサイトの運営者は認証局に署名を受け、発行してもらった証明書をサーバーに配置し、公開します。

・証明書はX.509の仕様に基づいたものである。
・証明書作成に際して、認証局からハンコをもらったものをサーバに配置する。
・証明書にはハッシュ値があり、元のメッセージが改ざんされていないかを確認するために使用されます。
・証明書の中にあるアルゴニズムの暗号化は、過去は1024bitの暗号強度でしたが、現在は2048bitの暗号強度です。
　※証明書を長く更新期間があると、暗号強度がレベルが低いままであるためセキュリティ的に問題ありです。


ちなみにCAは認証局のことを意味します。

ssl通信についての調査

■■■■暗号化通信■■■■

インターネットのSSL通信は
この2つの方式を合わせています。

■■共通鍵方式■■

お互いに解読するための鍵を持つ。

■■公開鍵方式■■


片方だけが秘密鍵を持つ。通常WEBサーバ（負荷分散装置）側が持つ。

①クライアント端末側が、公開鍵を使って暗号化
②サーバ側で秘密鍵を使って復号化。

公開鍵方式のアルゴニズム
RSA

そこで問題があります。この公開鍵は本物なんですか？？
⇒それを証明する仕組みが電子証明書です。

別名でデジタルIDまたは証明書と呼ばれます。


以下サイバートラスト


①SSL暗号化方式をWEBサーバ側とクライアント側で決める（暗号化するアルゴニズム等を決定する。）

②サーバ側が証明書をクライアント側に送付して、クライアント側は証明書を確認する。

③クライアント側は、サーバから送付された「Webブラウザは共通鍵の元となるデータを作成し、それをサーバからもらった公開鍵で暗号化してサーバに送る」

④サーバ側で秘密鍵を使って復号化して、共通鍵を取り出す。

これ以降、お互いで持っている共通鍵を使用して暗号化通信を行う。