IT回顧録

 SQLserverにID認証するとき、ID/PWは平文だと思っていたのですが、 Java(というかJDBC)だと暗号だということを初めて知りました。 ついでに、sqlcmd.exeで接続するときは？と思って、WireSharkで観察してみると・・・ TLS1.2(WindowsOSでTLS1.2に制限しているせいですが)でした。 ID/PWらしい暗号データを送った後は平文(0x00がASCIIデータにくっついているのでUTF-8かUTF-16かな？)で送っているみたい。（気が向いたら、文字コードを特定してみよう） SQLserver側で暗号通信強制（構成マネージャの「MSSSQLSERVERのプロトコル」プロパティにある「強制的に暗号化」を「はい」にする）にしたら、sqlcmd.exeでは接続できなかった。。。 ManagementStudioだと、暗号強制「はい」「いいえ」の両方でも問題なし。 （「いいえ」でもID/PWのところだけ暗号通信） 認証のところが暗号通信なのはいつからなのだろう？ サーバセキュリティ診断で1433が開いていると「ID/PWが平文で流れるから」って言われるのが納得いかないです（笑

 JavaのプログラムからSQLserverにつながらなくなった、という話があったので調査。 Javaのプログラムの吐いているエラーログにはSSLv3とかTLS1.1で繋がらない、っていうのがありました。 接続先のSQLserverのサーバ機は、2012終息対応で2019にしました。 ついでに、TLS1.2だけにしました。 繋がらないのはそのせいで間違いないでしょう。 JavaはJava7を未だに使っているらしい。。。2015年に終了してるのではなかったろうか。 検証のため、TLS1.2だけにした2019にSQLServerをインストールして、Java7とJava8をインストール。sqljdbc41.jarを落としてきて、SQLServerに接続して ここ にある「ネットワークの暗号化を確認する」を実行するJavaプログラムを用意しました。 用意した、と言っても こちら のほぼマルパクリです。ありがとうございます。 （CLASSPATHの設定方法がよくわかってなかったので、難航しました。 　set CLASSPATH=.;C:\sqljdbc41.jar のように最初に.;が必要だった。 　Javaプログラム本体へのPATHが必要、ということかな。） WireSharkでlocalhostの通信を観察していると、 　Java7：TLS1.1でClientHeloを行っているが応答がないので終了 　Java8：TLS1.2でClientHeloを行ってなんか送って、そのあと平文で通信 という状態でした。 SQLは平文で通信するくせに、最初だけ暗号通信・・・。 そうか、IDとパスワードは暗号化しているのか。なるほど。 「Java8使えや」で終了にしよう。

 2023/09/12現在の話です。 edgeを起動するとなぜか「復元しますか」ダイアログが表示されます。 ググると「システムの　Microsoft Edge が終了してもバック グラウンドの拡張機能およびアプリの実行を続行する　をオフにする」というのが対策で出てきます。 でも「×」で閉じて、tasklit.exeを実行するとmsedge.exeがたくさんいる。 正しく終了してないのでは？？？ どうやらメニューの「Microsoft Edge を閉じる」を選択しないとmsedge.exeが全部終了しないみたい。（edgeの右上の「×」で閉じても残存する） chrome(FireFox派なのでほぼ使ってない)も同じなんじゃないかな？

WindowsServer2022で、WindowsFireWallをOSインストール状態のまま有効にしていると、ftp.exeで別FTPサーバに接続した際にlsコマンドとか発行すると応答がなくなります。 FireWallの通信規則を追加すればいいのだけど、どうだったかうろ覚えで検索すると、何故か「送信の規則にリモート21番を設定」なるページがヒット。 「え？？？」とか思いながら設定してみると、当然というか、状況変わらずｗ ７とかXPの時代は送信の規則も設定する必要があったのだろうか。。 「受信の規則」にリモート20番の設定をして解決しました。