  |
はてなキーワード: TLSとは
もうアラフォーになるんだけど、でも、夢は捨てきれていない。
劣っている自分でも、プログラミングなら負けないと言えるようになりたかった。
諦めればいいんだけど、でも、自分にはプログラミングしかない。
「コンピューターサイエンスのすべての分野に精通」してないのを恥じている。
いや、「インフォメーションエンジニアリングのすべての分野に精通」してないのも恥じている。
全部を上手くできない自分が、ただただ劣っていて嫌で仕方がない。
「コンピューターサイエンスのすべての分野に精通」している人がいるなかで、自分ができてないのが嫌になる。
なんで、自分にはできないんだと永遠に責め続けてしまう。できる人がいるのに、どうして自分にはできないのか。
全部できていたい、なんで全部できていないのか、それが自分の頭の問題だということを受け入れたくない。
UT入ってIS行くような人ができることが出来ないことに勝手に差を感じてる。
プログラミングが得意になるように頑張った。
お前は劣っているのだから、要領よく文系としては生きられないからと。
しかし、だからといってあきらめたくない。全部上手くできるようになりたい。
少しづつあがいてるけど、結局、やることなすことうまくいかない。
React/Vueみたいなフロントエンドフレームワークも作れてない。
出来てないことだらけなのに、まだ挑戦していたいと思ってしまう。
たぶん、脳の病気なんだと思うけど、でも、やめたくない
一等賞になれないのだろうけど、でも、一等賞を目指したくなる
この文章は作者の認知や信念を吹き込まれたAIが記述しています。そこまで間違ったことは言ってないつもりですが、読む場合はその点考慮して。
---
| 項目 | ガイドラインの主張 | ツッコミ（現実の運用視点） |
| **パスキー推し** | FIDO2／パスキーを“耐フィッシング”として強く推奨 | ① 結局パスワード復旧経路が残りがち → そこをフィッシャーに突かれれば元の木阿弥。 ② パスキー同期には「SE（セキュアエレメント）搭載端末＋クラウドバックアップ＋ビッグテックアカウント」前提。本当に全利用者が持ち歩ける？失くした時の再発行フローはどれほど煩雑？ ③ 「パスワードマネージャー＋強制自動補完」のほうが導入コスト・学習コストともに圧倒的に低いのに完全スルー。 |
| **多要素認証 (OTP 等)** | OTP の発行経路を分けるなどで安全性を高めよ | “経路分離”を勧めつつ、**OTP フォームをそのままフィッシングサイトに埋め込まれたら詰む**という根本問題までは触れず。SIM スワップやプッシュ爆撃の最近例も載せないのは片手落ち。 |
| **HTTPS 周り** | 画像 1 枚でも非 HTTPS なら錠前外れるからダメ | この指摘は正論。ただし本質は HSTS/upgrade-insecure-requests を徹底させればほぼ自動解消。コントラスト比の話まで細かく書く割に *HSTS preload* への言及ゼロは惜しい。 |
| **ドメイン確認の啓発例** | 「正規ドメインを見つければ安心」的な“悪い例”を紹介 | “悪い例”を示す姿勢は良いが「じゃあ何を見れば良いの？」という代替基準を提示せずに終わっている。利用者教育に丸投げは厳しい。ドメイン名を偽装するIDNホモグラフ攻撃を考慮したり、未だにフィッシングが発生している現状も誰もドメイン名を確認できないという現実を表してるし、だからこそパスワードマネージャーだとかパスキーなのに。 |
| **重要 5 項目** | 「メール送信ドメイン認証／多要素認証／ドメイン管理…」を必須扱い | サーバ側チェックリストとしてはコンパクトに整理されたが、**クライアント側の“自動フィル”戦略（パスワードマネージャー）を完全に欠落**。エンドユーザ視点の即効性では一丁目一番地の対策なのに…。 |
---
1. **「パスワードマネージャー前提」のセクション追加**
* ドメイン単位の自動補完を“正解”として教え、手入力をさせない UX を推進。人間が URL チェックで勝つのは無理。
2. **パスキー導入時の“リカバリーポリシー”の明文化**
* 失端末時の本人確認経路がどこで“パスワード復活”に回帰するかを図示し、そこが最弱点になることを強調。
* パスキー非対応環境向けに、トランザクション署名（決済内容を端末に表示→同意タップ）の導入を例示。
4. **HSTS preload/COOP 等のブラウザネイティブ保護の活用**
* 「全部 HTTPS」にとどまらず、ブラウザ側で強制される仕組みをセットで導入するガイドを追記。
* パスワードでも“過去に保存された端末以外からのログイン要求は即ブロック＋アラート”など、実例付きで書くと◎。
---
#### 💡 まとめ
ガイドラインは **“事業者側の整備チェックリスト”** としてはよく整理されています。ただし**ユーザーが今日から実践できる“入力しない”系対策（パスワードマネージャー）を全く触れていない**のは惜しい。
「パスキーさえ入れれば万能」みたいな印象を与えないよう、**復旧経路＝フィッシング経路** になり得る現実と、**導入ハードルの高さ** を明確に書き加えるとより実践的になりますね
---
| PDF の記述 | 見落としている現実 |
| **「多要素認証を必須にしよう！」** ログイン・設定変更・送金時に TOTP／SMS／メール OTP を組み合わせるべし、と力説 | **中継型フィッシング（AitM リバースプロキシ）で OTP はその場で横取り可能。** 利用者がトークンを入れた瞬間、攻撃者はセッションを生成→被害成立。 → *“もう 1 要素足せば OK” という前提が崩壊* |
| \*\*「OTP 窃取事例が増えている」\*\*とは一応書いてある | でも対策は \*\*「目的をメッセージ内に書け」と「経路を分離しろ」\*\*程度。 → **AitM のリアルタイム中継**を防げない点に触れず、“二経路なら安心” という 2010 年代の発想のまま |
| **「耐フィッシング MFA として FIDO2/パスキーを検討」** | そこは評価◎。しかし **パスキー復旧＝パスワード経路** をどう守るかが不在。 復旧時に結局メール＋リンクでパスワード再設定→AitM で焼け野原、は書いていない |
### 🔥 リバースプロキシ型フィッシング (AitM) の流れ
1. 攻撃者が `evil-proxy.example` を立て、裏で正規サイトへリバースプロキシ。
2. 被害者がログイン → パスワードも TOTP も**その場で**中継。
3. 攻撃者は正規サイトで完全なセッションクッキーを取得し、以後 OTP 不要で好き放題。
> **結論：TOTP／SMS OTP は「パスワード再利用勢」への応急処置**に過ぎず、
> **パスワードマネージャー＋一意乱数パスワード勢**には負担だけを増やす事になる。
---
| 目的 | 具体策 |
| **AitM への真の対抗策** | - **パスキー／FIDO2** を「ユーザー検証付き＋同一サイト限定」で推奨 - **トランザクション署名**（金額・宛先を端末に表示→確認タップ）を必須化 |
| **“上級者は OTP 要らない” オプション** | - **リスクベース認証**：信頼済み端末＆一意パスワードなら OTP 免除 - **デバイスバインディング**：Cookie＋TLS ClientCert で本人端末限定ログイン |
| **復旧経路が最弱点** | - パスキー利用者でも **「復旧は対面確認 or 物理郵送コード」** 等で別経路を強固に - 「メールリンクだけ復旧」は明示的に非推奨と記載 |
| **ユーザー負担の最小化** | - **「OTP 全面必須」ではなく“高リスク操作のみ step-up MFA”** 方針を明文化 - パスワードマネージャー利用者には「危険を理解した上で OTP オフ」チェックを用意 |
---
もっと言うなら、MFA として FIDO2/パスキーを検討がおかしいかな。
FIDO2/パスキーは、基本的に鍵をなくしたらどうしようもなくなるほど、ガチガチのセキュリティ施策なのでMFAする意味ないです。パスキー一要素だけで、全然セキュリティ強度は高いです。
ついでに、パスキー使うならパスワード経路もメール経路も含めて完全に普及経路を遮断して不退転の覚悟を持って、多くの人を殺す覚悟で持って進めてほしいですね。☺️
それくらいパスキーは劇薬です。本気で覚悟持ってパスキー利用に進みますか？☺️
半端に混在させるくらいなら、
TLSと何もかも一緒ってわけではなくて、あくまでアナロジーでしょ
信頼の検証方法とかそういう難しい話ではなくて、トポロジー的なこと
TLSの検証の進め方は末端であるリーフ（たとえばhatelabo.jpのサーバ証明書）から中間CA、ルートCAっていう風に下から上に辿る
DNSも同じツリー形式だけど、DNSの場合はルートからリーフに向かって問い合わせをする（.に問い合わせて、jpに問い合わせて、hatelabo.jpに問い合わせる）
戸籍は下方向(子孫)はそもそも既知なことが多いから、上位(祖先)方向へ向かって辿ることが多いよね
競プロと機械学習系のクソコード・クソジャークっぷりが取り立たされてるけど、クソコード・クソジャークっぷりは何も競プロerと機械学習erの専売特許ではない。
「運転免許証にもICチップがあるからマイナカードと同じことができる」と勘違いしている人が多いので以下解説。
以上の理由により、今後オンラインでの本人確認はマイナカードに一本化されていく。運転免許証はオンラインで本人確認に使えなくなっていく。
anond:20221228030607 の続き。
Apple製品のようなスマートさは期待してなかったがある意味予想通りで期待通りだった。
たとえば2の登録では「家電登録ボタンを押す」→「機種カテゴリを選択」→「品番を選択または家電本体のQRコードを読ませる」という流れになるが、機種カテゴリを間違えると品番は見当たらないしたとえQRコードを読ませてもエラーとなる。なお本機の機種カテゴリは「自動計量IH炊飯器」であって「炊飯器」ではないので、上から順に見て「炊飯器」だと思って選ぶと登録できない。まあこれは注意すれば回避できるので大した問題でも無いが。
厄介なのは3の無線LAN設定時、ここでは背面のQRコードを読ませるのが必須なので意気揚々と設置した後にもう一回持ち上げて裏を向かせる必要がある。それなりに重量も大きさもあるのでペラ1枚の注意書きぐらいは欲しいところ。
アプリでの操作を大前提としている作りなのでアプリの使い勝手が重要になるが、キッチンポケットというパナの調理家電用アプリの一機能としている時点で不安があったがまあお察しというか、やはりこれは「日本の家電」であって「ガジェット」ではないという感想。
たとえばお櫃（内釜）を入れずに炊飯予約を入れるとどうなるか？
内釜なしで炊飯することは出来ないので、画面上では「お櫃が設置されていない」というエラーが表示される。ここまではいい。
問題はこのエラー解除には本体で「キャンセル」ボタンの押下が必須。アプリを一度落とそうが必ず本体側でのキャンセル操作が必要。
どうせお櫃をセットしないと動作しないガードが掛かっているのに、予約キャンセルボタンをわざわざ押させる理由はなんなんだろうか。
アプリ上で炊飯時間・炊飯量・炊飯の速さの組み合わせを3パターン登録できるが、毎日・毎週といった設定や炊飯2回分の先行設定も不可。つまり毎日毎回必ず手作業で予約しろということ。
毎日自動炊飯されると、手入れを忘れたときに衛生面に問題が出るとか色々考慮したのかもしれないが普通に考えてこれは不便だ。
設定の約1時間15分前に「そろそろ炊飯始めるぞ、予約変更するなら早くしろ」というアプリ通知が飛び、1時間前に炊飯前の計量が開始されて時間通りに炊き上がる。
炊き上がるとアプリ通知が飛んでくる。この辺は予想通り、期待通りなので特に何もなし。
米と水の計量時に多少音がするだけ…と思っていたら、炊飯中はずっとファンの音がする。
後部の底面から吸気して、内釜の方に送風しているようだがいまいち用途がよくわからん。この辺は取説にも余り詳しく書かれていない。
なお蒸気レスで炊飯できるという記載は無いが炊飯中に蒸気が出ている気配は無い。
ちなみに本機のボタンは「静電式ボタン」と呼ばれるもの。物理的に押し込むのでは無く、触れるだけで反応する。
記念すべき初回の炊飯中、ふと水平状態が気になり（キッチンの端っこ、IHコンロの段差部分に設置したため）iPhoneの水準器で水平状態を確認してたらキャンセルボタンに触れてしまったらしく、文字通り炊飯がキャンセルされるというイベントが起きた。普通の炊飯器であれば再度炊飯開始ということが可能だと思うが、本機は計量からの自動炊飯器なので計量からやり直さなければならない。つまり内釜に入った水とコメは捨てるか鍋にでも入れて自分で炊くしかない。泣く泣く捨てた。そして二度と本体には指1本触れないと誓った。
本機の購入キャンペーンで貰った米（確かコシヒカリ）だが特に可もなく不可もなし。特に味に拘りはないがトップバリュのパックご飯よりは美味しい…ような気がしないでもない。
内釜とその蓋については洗い物ついでに洗えるのでさして面倒ではないが、蓋はパッキンが付いている（取り外し不可）ので完全乾燥させるには放置するしかない。小さい水滴を気にしないなら、布巾で拭けるだけ吹いてセットして次の日の炊飯というのも有りだとは思う。
内釜は一応コーティングされてるようだが一回使っただけでうっすら傷というか跡が付いたのでコーティングの寿命は余り長くないかもしれない（使った杓文字は本機の購入キャンペーンで貰った木製のもの）。
地味に本体とお櫃を繋ぐ連結パッキン部分も毎回の手入れ箇所となっている。ここは炊飯直後には水滴が付いているので放置すると禄なコトにはならなさそうだし、外からは目に見えにくいという厄介さがある。カビとか生えたりしたら恐怖なので取り外して洗えるようにして欲しい。
水タンクは毎日入れ替えることになるからか毎回の手入れ指定はされていないが、水を扱っているので経年で水垢とかが付くのだろうなあという予感がある。
この水タンク、内側もかなり複雑な形状で手入れはかなりし難い。水垢が目立ってきたら補修部品と交換した方が絶対早い。
ワイが代わりにchatGPTに聞いてやったやで
中継サーバー上の電子メールは、暗号化されていない場合は、中継サーバーの管理者や攻撃者によって盗み見られる可能性があります。ただし、多くのメールプロバイダーは、暗号化された通信プロトコル（例：TLS）を使用して、中継サーバー上の電子メールを暗号化しているため、中継サーバー上で盗聴される可能性は低いです。
2.電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
インターネット上のどこかに、怪しい第三者が設置したサーバーが存在する可能性はあります。このようなサーバーを使用して、電子メールを送信すると、そのメールが第三者によって盗聴、改ざん、または中断される可能性があります。
3.電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
P2Pで暗号化された電子メールを送信するために使用できる一般的な技術には、Pretty Good Privacy（PGP）、GNU Privacy Guard（GPG）、またはS/MIMEがあります。
4.「3.」の実現は中小企業で導入するのは難しいものなのか？
PGP、GPG、S/MIMEなどの技術を中小企業で実装することは可能ですが、技術的な知識とスキルが必要です。また、P2Pで暗号化された電子メールの受信側も同じ技術を使用する必要があります。中小企業では、公開鍵暗号化を使用したエンドツーエンド暗号化を提供するメールサービスを利用することが簡単で効果的な解決策となる可能性があります。
5.中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
中継サーバーを経由することによって、メールアドレスが漏洩する可能性があります。この漏洩によって、スパムメールの送信元として使用される可能性があります。
6.例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
Wiresharkなどのネットワークプロトコルアナライザーを使用して、ネットワーク上を流れるデータを盗聴することは可能です。ただし、一般的には、電子メールの内容は、中継サーバー上で暗号化されているため、中継サーバー上での盗聴による情報漏洩がより問題となります。また、会社のネットワーク内でのデータ盗聴は、セキュリティポリシーや監視機能の設定によって防止される場合があります。
2. 電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
3. 電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
4. 「3.」の実現は中小企業で導入するのは難しいものなのか？
5. 中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
6. 例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
会社で日常的に契約書のPDFや重要な文書を送付しあってるけど、あれ、内容が漏洩することはないの？
あと、会社の情シスから、「迷惑メールが突然来るようになるのは、第三者が設置した中継サーバーでメールアドレスが漏れてしますから。インターネットは不特定多数のサーバーを経由するから、ITを囓ったものなら誰でもそれは分かる」と言われた。確かにインターネット（というかTCP/IP通信）では冗長化されたネットワーク上でパケットが送付されるが、第三者の個人が設置した野良サーバーを、会社から送付されたメールのデータが経由するものなのか・・・？
送信プロトコルとしてSMTPがあり、受信はPOP3、IMAPがあるのは知ってる。
1.について： TCP/IP通信では冗長化されたネットワークをパケットが通るのは分かるが、例えばGmailからOCNのメールに送られるとして、都内在住のマンションに住むある悪意を持った人物が設置したグローバルIPを持つ野良のサーバーを経由して送られる、なんてことがあるのか？ あるとは思ってなかったのだが。。。
2.について： 上と同じ。
3.について： S/MIMEかな？ PGPは会社で使用されているのは見たことがない。
4.について： S/MIME、PGPは、例えば社員400名くらいの小規模な弊社でも導入は容易なのだろうか。Microsoft 365のExchange Serverの設定がいるの？
5.について： 情シスがこれ（メールアドレスは中継サーバーで漏洩するもの）を気にしていた。だから、重要な文書はメールで送ったりするな・・・と。そうなのか？ 初めて知ったのだが。。。メールアドレス漏洩は、リスト型攻撃みたいに文字列(@の左側)を試行して特定ドメインに送付され、届かなければ存在しない、届けばその文字列のアドレスは存在する、みたいなやり方とか、あとダークウェブで入手するものとか、そうだと思ってた。
6.について： 弊社の情シスが言うには、メールの盗聴というのは容易に可能だから、メールでPDFの給与明細を送付するなんてことは絶対にできないらしい（でも、普通にしてる気はするけど・・・）。確かに電子メールはネットワーク上を平文で送付されるかもしれないが、パスワード付きPDFにすればいいし、給与明細をWebサイト閲覧の形にしてTLS通信させればいいじゃん。そういうクラウドサービスあるんだし。そもそも、社内のHUBに悪意ある第三者がLANケーブルつないでパケットキャプチャするとか、実現の難易度高すぎるから、それは想定しなくていいんじゃないの？
ていうのか、疑問。誰か教えて。
CoreKeeper側で apt に依存しているっぽいので、Ubuntu でやった方が楽だと思います。
Ubuntu 20 TLS でやる場合、/home/steam/Steam/ が /home/steam/.steam/ になってたと思うので、環境に合わせて読み替えてください。
dpkg --add-architecture i386 add-apt-repository multiverse apt-get update apt-get dist-upgrade reboot
useradd -m steam passwd steam gpasswd -a steam sudo
sudo -u steam -s cd sudo apt install steamcmd ln -s /usr/games/steamcmd steamcmd ./steamcmd +login anonymous +app_update 1007 +app_update 1963720 +quit
cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ ./_launch.sh
Press Ctrl + C for Stop Core Keeper Dedicated Server
mkmir -p -m 775 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds chown steam:steam /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old world file (0.world.gzip) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds
Copy old setting file (*.json) to
/home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/
chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip chmod 664 /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/*.json
vi /etc/cron.hourly/corekeeper_backup #!/bin/bash cp -a /home/steam/.config/unity3d/Pugstorm/Core\ Keeper/DedicatedServer/worlds/0.world.gzip /home/steam/worldbackup/0.world.gzip.`date '+%Y%m%d%H%M%S'` cp -a /home/steam/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt /home/steam/worldbackup/CoreKeeperServerLog.txt.`date '+%Y%m%d%H%M%S'` chmod 777 /etc/cron.hourly/corekeeper_backup sudo -u steam -s cd mkdir worldbackup
sudo -u steam -s cd ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/ nohup ./_launch.sh tail -f ~/Steam/steamapps/common/Core\ Keeper\ Dedicated\ Server/CoreKeeperServerLog.txt
利用者の問題か、サーバーの問題かわかりませんが人数が10人超えると CPU4コア/メモリ4G/100Mbps で結構ラグかったです。
今は CPU6コア/メモリ8G/1000Mbps で動かしています。
６-８人以上で２-３時間サーバー動かしてると、Unityのライブラリがsegfault起こして、Core Keeper Dedicated Server が落ちます。
ログ取れたのでバグレポしましたが、改善するまでは不特定多数が好き勝手するサーバーみたいなのを長期運用するのは厳しいかなと思います。タイミングによってはアイテムロストしてしまうので。
