Hi there 👋

事始め 会社ではL7プロキシの運用・開発をしている。 複数のEP（ドメイン）を持っている。 複数のドメインをひとつのL7プロキシ（単一のIP）でさばいている。 さて、これはいったいどの様に実現しているのか？というのが今回の議題。 IPアドレスはDNSによって単一のドメインと紐づけられる。と自分は認識していたが、これが誤りだった。 そして、自分は、会社に入るまでホストヘッダーという概念を全く分かっていなかった。 HTTPにはホストヘッダーというものがあり、これによって単一IP上に複数のドメインを保持することができるようになる。 そして、ポイントはやはり、HTTPはL7レイヤーであり、IPはL3レイヤーであるというところに落ち着くと思う。 前提 DNSでのIPアドレスとドメインの紐づけは一対一ではなく、一対多であった。ここがすごく大事なところでした。 そして、自分はホストヘッダーについて理解していなかった。 nginxを使ってバーチャルサーバを立てる chatgptから 単一の物理サーバー上で複数のウェブサイトやアプリケーションをホストするために使用される機能です。それぞれのバーチャルサーバーは、異なるドメイン名やサブドメインに対応して、個別に設定されたリソース（例えばウェブページやアプリケーションのファイル、SSL証明書、ログファイルなど）にアクセスを提供します。 Nginxでは、これらのバーチャルサーバーを「サーバーブロック」として設定ファイルに記述します。以下は、Nginxでのバーチャルサーバー設定の基本的な例です： server { listen 80; server_name example.com www.example.com; location / { root /var/www/example.com/html; index index.html index.htm; } error_page 404 /404.html; location = /404.html { root /var/www/example.com/html; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /var/www/example.com/html; } } ホストヘッダーの役割 chatgptより HTTPのホストヘッダーは、HTTPリクエストを送信する際に非常に重要な役割を果たします。このヘッダーは、クライアントがリクエストを送信する際に、どのホスト（ドメイン名またはIPアドレス）とポートに対してリクエストが意図されているかを指定するために使用されます。特に、一つのサーバーが複数のドメインをホスティングしている場合（仮想ホスティング）、ホストヘッダーがないとサーバーはリクエストがどのウェブサイトに対してなのか判断できません。 HTTP/1.1ではホストヘッダーは必須とされています。これは、HTTP/1.0と異なり、サーバーが複数のドメインをホストしている状況が一般的になったためです。リクエストにホストヘッダーが含まれていない場合、サーバーは400 Bad Requestのエラーを返すことが多いです。 DNSのAレコード 複数のサブドメインが同じサーバーのリソースを指す場合、それら全てに同じIPアドレスを割り当てることが一般的です。 例えば、次のように設定することができます： www.example.com → 192.0.2.1 mail.example.com → 192.0.2.1 ftp.example.com → 192.0.2.1 これらのサブドメイン全てに同じAレコードのIPアドレス（192.0.2.1）を指定することで、一つのサーバーが異なるサービス（ウェブ、メール、FTPなど）を提供することができます。これは特に、ホスティングサービスが複数のウェブサイトを単一の物理サーバーで管理する場合などに便利です。また、メンテナンスやアップグレードが必要な場合にも、一箇所で変更を行うだけで済むため効率的です。 ...

プロが使いがちなシェルです まあ自分はこだわりとかなかったので、bashを使っていたのですが、先輩たちのターミナル裁きを見ていると、なんかすごいんですよね。 queryとか出して過去のコマンドを一発で実行したり、tmuxとかで複数立ち上げたり、まあとにかくすごい。 でね、まあzshというのを使っているっポイのですわ。 ということで、zshのについていろいろ書いていこうと思います。 How to install sudo apt install zsh chsh -s $(which zsh) sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" (oh my zshのインストール) 色々調べていい感じにカスタマイズしてください

背景 k8sを使うにはcontainerdを使わないといけなくて、containerdのクライアントがnerdctlなんですよ。しかし、コンテナ関係と言えばdockerな訳で。githubとかで公開されているシェルスクリプトはdockerコマンドが使われている。全部書き直すのめんどくさすぎる。 そんな時にどうするか？エイリアスも上手くいかな。じゃあどうするか？そんな時のちょい技。 ちょい技 sudo vim /usr/local/bin/docker #!/bin/bash # Redirect docker calls to nerdctl exec nerdctl "$@" sudo chmod +x /usr/local/bin/docker これで全てのdockerコマンドがnerdctlにリダイレクトされます！！素晴らしい。

Athenzを完全理解したい願望 はい、書いてある通りです。athenz、理解したいです。 正直、個人開発レベルでは全然理解しなくていいやつです。しかし、大きな企業で、多くのサービスが動いていてサービス間でAPIを使い合いたいとかってなると必須の技術になると思います。いくら内部ネットワークとはいえね、認証された人だったりサービスのみにサービスの利用を限定しないと、もし仮に内部ネットワークに攻撃者が入ってしまった時に好き放題やられてしまうからね。 ということで、athenz完全理解を目指してやっていきたいと思う。 流れ athenzの各コンポーネントを紹介します。 athenzで使われているRBACについて説明します athenzを自宅のクラスターにインストールします インストールしたathenzを使って色々と試してみたいと思います。（プロバイダとテナントの通信、擬似攻撃者になってみるなど） そもそもathenzとは アプリケーション間のアクセスを制御するためのプラットフォーム、ですね。 アクセス制御ってのは、REST APIなどのリソースに対して、権限を与えることだよね。 アクセス制御を実現するための構成要素としては、３つあって、識別、認証、認可、の３つだね。 で、athenzの認証だけど、RBACってのが使われているんだよね。 rbacとは アクセス対象を役割ごとにグループ化する。んで、グループに対して権限を与える感じ。このグループのことをroleっていうんだよね。 大事なのは、人ではなく、roleに権限を与えるってこと。で、人をroleに追加する。 ちなみに、roleには色々あって、例えばcrudが全部できるroleも作れるし、閲覧しかできないroleを作ることもできる。 ちなみに、各roleに与える権限のことをポリシーという。これも大事。 roleにpolicyを付与する、という感じ。 リソースの提供者をプロバイダ、リソースの利用者をテナントという。そして、中央にathenzがいる。 で、識別情報のことをAthenz serviceとかっていう。ここがちょっと難しいね。あとでドメインって名前も出てくるけどさ。 athenzのアクセス制御の流れ テナントがプロバイダにアクセスするとき、まずテナントは中央のathenzにトークンを（ロールトークン）発行してももらう。このとき、テナント自身の存在を証明するためにx509証明書を提示する。（ここで一つ目の疑問。誰がx509証明書を発行してくれるのか？）で、発行してもらったトークンをhttpヘッダーにつけて、プロバイダにアクセスする。 プロバイダではathenz-proxyがapiの前で動いている。んで、中央にいるathenzから取得しておいた情報とアクセスを照らし合わせて、apiにプロキシするかしないかを決定する感じです。 アーキテクチャとコンポーネント 1. Management Server (ZMS) The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations. Key Features: Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies. Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources. Audit Trails: Keeps a record of all configuration changes for security and compliance purposes. REST API: Provides APIs for managing domains, roles, and policies programmatically. Storage: Persistently stores configuration data in databases like MySQL. Athenz is a robust system for managing service-to-service authentication and fine-grained access control through its primary components: ZMS (Management Server), ZTS (Token Server), and its User Interface. 1. Management Server (ZMS) The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations. Key Features: Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies. Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources. Audit Trails: Keeps a record of all configuration changes for security and compliance purposes. REST API: Provides APIs for managing domains, roles, and policies programmatically. Storage: Persistently stores configuration data in databases like MySQL. 2. Token Server (ZTS) The ZTS is the runtime component responsible for generating and validating short-lived tokens and certificates that services use to authenticate with one another. Key Features: Token Issuance: Issues Access Tokens (JWTs) and Role Tokens for authorization. Tokens are short-lived, improving security by reducing exposure to stolen credentials. Certificate Issuance: Provides short-lived X.509 certificates for mutual TLS authentication between services. Decentralized Authorization: Services can independently validate tokens or certificates using the ZTS public keys, reducing reliance on the ZTS during runtime. Dynamic Trust: Works seamlessly in dynamic environments like Kubernetes, issuing tokens based on pod identities. Integration: Compatible with OAuth 2.0 and OIDC for standardized authentication. 3. User Interface Athenz includes a user-friendly web-based UI that enables administrators and users to interact with the system without directly accessing APIs or configuration files. Key Features: Role and Policy Management: Intuitive interfaces for creating and managing roles, policies, and resource permissions. Domain Browsing: Easily navigate through domains and view their configurations. Audit and Reporting: Visualize audit logs and track changes to roles, policies, and resource access. Ease of Use: Simplifies complex RBAC configurations into a graphical and interactive platform, making it easier to onboard new administrators. コンポーネントのまとめ Summary of Workflow: Setup Phase: Use the ZMS or UI to define domains, roles, and policies. Runtime Phase: Services request tokens or certificates from ZTS to authenticate with other services. Decentralized Validation: Tokens are validated locally by consuming services using ZTS-provided public keys. 一旦用語説明 atehnz service ；アクセス元を識別するためのInfo role : 同じ権限を持つAthenz serviceをグループとしてまとめたもの。Athenz serviceを追加する感じ。 Policy : Roleでどのようなことが行えるのかを記したもの Domain : Athenz Service, Role, Policyを管理する名前空間 x509証明書：athenz serviceであることを証明するもの。 トークンの種類 設定 テナント側： まず、アクセス元を識別するためのathenz serviceを作成する必要がある。 そして、x509証明書を取得する必要がある。（これは秘密鍵を生成して、どこかにcsrを送って、証明書を配布してもらう、という流れだった気がするのだが） ちな、環境によってはこれらが自動化されていることもある。 ...

nginxのメトリクスとログをモニタリングをする メトリクスデータは以下のように流す nginx -> vector -> kafka -> opensearch/influxDB という感じで、nginxから出た生ログをvectorでとり、kafkaに送信、kafkaから、opensearchとinfluxDBがそれぞれとってくる、という流れにするのが良さそう で、nginxがログを吐き出し/var/log/nginx/access.logとvectorを同じネームスペースで扱いたいので、この二つは物理マシン上にインストールするという流れにしたいと思う。 環境構成 以下の3つのマシンを使う delta (100.64.1.48,192.168.3.1) : 192.168.3.1/24のルータ,kafka, kafka-ui, opensearch master (192.168.3.8) : プロキシサーバ（nginx）、vector gamma/zeta/　: オリジン kafkaを導入するdocker composeの設定 services: kafka-broker: image: apache/kafka:3.7.0 container_name: kafka-broker ports: - "${KAFKA_BROKER_LOCAL_PORT}:9092" environment: KAFKA_NODE_ID: 1 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: "CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,PLAINTEXT_HOST:PLAINTEXT" KAFKA_ADVERTISED_LISTENERS: "PLAINTEXT_HOST://localhost:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://kafka-broker:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_PROCESS_ROLES: "broker,controller" KAFKA_CONTROLLER_QUORUM_VOTERS: "1@kafka-broker:${KAFKA_BROKER_CONTROLLER_PORT}" KAFKA_LISTENERS: "CONTROLLER://:${KAFKA_BROKER_CONTROLLER_PORT},PLAINTEXT_HOST://:${KAFKA_BROKER_LOCAL_PORT},PLAINTEXT://:${KAFKA_BROKER_PUBLIC_PORT}" KAFKA_INTER_BROKER_LISTENER_NAME: "PLAINTEXT" KAFKA_CONTROLLER_LISTENER_NAMES: "CONTROLLER" KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0 KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1 KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1 KAFKA_LOG_DIRS: "/tmp/kraft-combined-logs" kafka-ui: container_name: kafka-ui image: provectuslabs/kafka-ui:v0.7.2 ports: - "${KAFKA_UI_PORT}:8080" depends_on: - kafka-broker restart: always environment: KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS: kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} init-kafka: # kafka-topics コマンドを使いたいので confluenticsのコンテナを利用 image: confluentinc/cp-kafka:7.6.1 container_name: init-kafka depends_on: - kafka-broker entrypoint: ["/bin/sh", "-c"] command: | " # blocks until kafka is reachable kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list echo -e 'Creating topics' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --create --if-not-exists --topic nginx-log --replication-factor 1 --partitions 1 echo -e 'Successfully created :' kafka-topics --bootstrap-server kafka-broker:${KAFKA_BROKER_PUBLIC_PORT} --list " opensearchを導入する設定 version: '3' services: opensearch-node1: # This is also the hostname of the container within the Docker network (i.e. https://opensearch-node1/) image: opensearchproject/opensearch:latest # Specifying the latest available image - modify if you want a specific version container_name: opensearch-node1 environment: - cluster.name=opensearch-cluster # Name the cluster - node.name=opensearch-node1 # Name the node that will run in this container - discovery.seed_hosts=opensearch-node1,opensearch-node2 # Nodes to look for when discovering the cluster - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 # Nodes eligible to serve as cluster manager - bootstrap.memory_lock=true # Disable JVM heap memory swapping - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" # Set min and max JVM heap sizes to at least 50% of system RAM - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} # Sets the demo admin user password when using demo configuration, required for OpenSearch 2.12 and later ulimits: memlock: soft: -1 # Set memlock to unlimited (no soft or hard limit) hard: -1 nofile: soft: 65536 # Maximum number of open files for the opensearch user - set to at least 65536 hard: 65536 volumes: - opensearch-data1:/usr/share/opensearch/data # Creates volume called opensearch-data1 and mounts it to the container ports: - 9200:9200 # REST API - 9600:9600 # Performance Analyzer networks: - opensearch-net # All of the containers will join the same Docker bridge network opensearch-node2: image: opensearchproject/opensearch:latest # This should be the same image used for opensearch-node1 to avoid issues container_name: opensearch-node2 environment: - cluster.name=opensearch-cluster - node.name=opensearch-node2 - discovery.seed_hosts=opensearch-node1,opensearch-node2 - cluster.initial_cluster_manager_nodes=opensearch-node1,opensearch-node2 - bootstrap.memory_lock=true - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" - OPENSEARCH_INITIAL_ADMIN_PASSWORD=${OPENSEARCH_INITIAL_ADMIN_PASSWORD} ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - opensearch-data2:/usr/share/opensearch/data networks: - opensearch-net opensearch-dashboards: image: opensearchproject/opensearch-dashboards:latest # Make sure the version of opensearch-dashboards matches the version of opensearch installed on other nodes container_name: opensearch-dashboards ports: - 5601:5601 # Map host port 5601 to container port 5601 expose: - "5601" # Expose port 5601 for web access to OpenSearch Dashboards environment: OPENSEARCH_HOSTS: '["https://opensearch-node1:9200","https://opensearch-node2:9200"]' # Define the OpenSearch nodes that OpenSearch Dashboards will query networks: - opensearch-net volumes: opensearch-data1: opensearch-data2: networks: opensearch-net: nginxを導入する設定 これは普通に ...

Real world httpに書いてあることを殴り書きしていきます 開発環境 の前に、lanのipアドレスを書いておきたいです。 100.64.1.27 : alpha 100.64.1.61 : evn 100.64.1.48 : delta (K8SクラスタへのGWです) deltaの役割 前に、DHCPサーバとルータを作成する記事を書いた。 こちらの記事だね。 で、deltaはDHCPサーバ兼ルータという立ち位置です。

2024/11/1時点でのタスクリスト 開発関係 自宅のK8S上にecho-serverを立てて、proxyを複数立てて、さらにvipを立てて、vegetaで負荷試験ができるようにしたい。そして、様々なメトリクスが取れるようにしたい。どうやるんだろうか。流れ的には、だいぶ遠回りになることは承知だが、 まず、real-world-httpを読みたい。これは、だいぶ長いのよね。メモを取りながら進めていく。最終目的はプロキシ2台とecho-server1台の構成で、vegetaで負荷をかけられるようにすること。 うちのも参考にするといいかも。そして、壊して学ぶk8s的な本を買ったので、それを読んで、goで書いたecho-serverをラズパイにデプロイするる感じでやりたい。これをいつまでにやるかだけど、 ISUCONの過去問を解きましょう。今年のISUCONにおそらく白木さんと出ることになります。足を引っ張りたくないので頑張ります。 ーー＞isucon14の申し込みが始まったという話です。頑張りましょう。 会計ソフトを導入する。この辺が良さそう https://ledger-cli.org/ 合同会社の設立を進める I and shiraki-san decided to develop GSLB using go lang. It is going to be funny Learn DNS （こっちはかなりいい感じで進んでいる。） –> Done Learn How to write packer parser using Go on TCP Layer. It is also going to be funny. 例の競馬システムを動かす時が来た。自宅のk8sで動かせるようにmanifestファイルを書いてください。よろぴくお願いしますです。 Go言語でdistributed file systemを作ってくれ！このyoutubeを見てでもいいし、goで分散システムを作ろうって入ってきたあの本でもいい。どっちでもいい。ただ、後者だとk8s上に作った分散システムを展開するので、上のやつとも親和性が高い気がしています。はい。 その他 毎朝早く起きてくれ。23時に寝て0630に起きる生活ができると最高だ。 早く業務委託で何かしらの案件を取ってきて売れ。 早くyoutubeチャンネル開設して、経費生活を始めてくれ！ 長期目線 簿記2級とってくれ！ 土地をどこに買うかかんがえてくれ！！そして貯金しろ！！マジな話、生活費8万と、共通貯金口座5万以外は全部あっちに回してくれ。 つまり、月のクレカ支払いに使えるお金は17万ということになる。保険で10マン落とされるので、残り7万か。まあそんなものやろう。

ECDH完全理解した。 参考 ECDHを紹介するyoutube 楕円曲線暗号をビリヤードに例えている例 ECDHの説明 かなり面白いね。ECDH。 まず、楕円曲線上で足し算というものを定義する。 これは、ビリヤードである。二点を決めて、その直線を引くと新たに楕円曲線と交わる点が生じる。それをx軸に対象に折り曲げた点、これを足し算の結果とする。 a + b = c ここで、p + p = 2pというものを定義可能である。pというのは、接線となる。 で、ここで不思議なのが、以下の結合法則が成り立つこと。 p + 2p = 3p 3p + p = 4p 2p + 2p = 4p 先に p + 2p = 3p 3p + p = 4p を計算して出した4pも 2p + 2p = 4p で出した４pも同じ点になる。これは面白い。 でだ、 こんな感じで最初の点Gを決めて、k倍した点Q Q = kP を求めることは簡単である。（例えば、k = 128の時は、2p+2p, 4P+4p,,,, 64p+64pで計算関数は少なく済む。） しかし、QとPからkを求めることは困難である。前から順番にやっていくしかないのである。 ということで、Qという値をサーバとクライアントで生成するんだよね。それぞれ、Q1,Q2. Q1 = K1P Q2 = k2P そして、Q1とQ2を交換します。opensslではRSAなどで署名が施されて交換されるので、真正性も担保される。 で、プリマスターシークレットを、 Q = K1K2P として、鍵交換が完了。これを元に共通鍵を生成して暗号通信がスタートする、という感じだ。 素晴らしい。 楕円曲線暗号のイメージは、以下のように説明されています。 ...

公開鍵暗号の体系を完全に理解した はい、鍵交換アルゴリズム、署名アルゴリズム、暗号アルゴリズム、暗号モード、ハッシュ の５つのセット（暗号スイート）を指定して通信を暗号化する。それが、俺が知っている暗号体系の全てです。 でですね、openVPNでクライアントとサーバの通信を暗号化しますよね。 その時に色々と証明書を発行すると思うんですよ。ただ、俺はどの証明書がどのように用いられるのかが全くわかっていなかった。 だから、今回、改めてopenVPNでクライアントとサーバを構築する際の証明書の役割などを確認したいと思う。 過去の僕の記事 basic client site to site routeing いつも参考にしている記事 qiita では追っていきましょう 認証局 (CA) の設立 ここから始まっているっぽいんだよね。 $ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: path/to/easy-rsa/easyrsa3/pki CA証明書の生成 $ ./easyrsa build-ca パスフレーズが聞かれる。 ここで、秘密鍵と公開鍵がすでに生成されている。認証局のね サーバ証明書の生成 $ ./easyrsa build-server-full server nopass ここで、CA証明書を生成したときのパスフレーズを再び入力する。 これでおそらく、サーバの公開鍵に署名がされる。(CSRも済んでいる) DH鍵の生成 ここでDH鍵が生成されるのか。なぜだ？？TLSでのDH鍵は毎回違うものが使われるのではないのか！？ なるほど、chatGPTに聞いたのであっているかはわからんが、この段階で生成されるものは、DHパラメータ（素数と生成元）だね。 これは納得だね。 つまり、 y = g ^ (x) mod p の、pとgが生成される。で、サーバとクライアントはお互い適当にxを選ぶわけですわ。はい完全理解。 ちなみに、ecdhを使って鍵交換をすることもできます。 証明書失効リストの生成（こちら、参照しているページでは間違っているので注意が必要） $ ./easyrsa gen-crl こちらも、CAの秘密鍵で署名するわけですね。 クライアント用秘密鍵の生成 $ cd easy-rsa/easyrsa3 $ ./easyrsa build-client-full username はい、ここでクライアントの証明書と秘密鍵を生成するわけですね。 で、証明書はCAが認証する必要があるので、再びパスフレーズを入れる感じになります。 ...

前提知識 TLSでは、 鍵交換アルゴリズムを使って共通鍵の材料となる値を交換し、共通鍵を生成し、その鍵を用いて通信が暗号化されるわけですね。 鍵共有に使われる暗号を、公開鍵暗号と言いますね。共通鍵は、共通鍵暗号です。 公開鍵暗号 RSA DH ECDH DEH = DH ephemeral ECDHE = ECDH epemeral DHとECDHは離散対数問題を使っています g^x mod p = y で、y,p,gが与えられたとき、xが求められないってことね 共通鍵暗号 RC4 (危殆化) DES = (危殆化) 3DES きたいか ChaCha20 AES = 最も使われていて安全 RC4 = ストリーム暗号 AES = ブロック暗号 ハッシュ関数 MD5 SHA-1 SHA-2 SHA-3 TLSの暗号スイートについて はい、これすごく大事なこと言います。TLSを使って通信が暗号化されるまでの流れですね。 TLSハンドシェイク 実際にTLSの通信が始まる でですよ。TLSハンドシェイクで何を決めているか？なんですが、以下を決めているわけですね。 鍵交換アルゴリズム 署名アルゴリズム 暗号アルゴリズム 暗号利用モード ハッシュ関数 鍵交換アルゴリズムは上に書いた、RSA,ECDHE,DHEです。 署名アルゴリズムは、RSA/ECDHEを指定できますが、ここは、発行したサーバ証明書の鍵の種類に依存します。ここすごく大事。 実は、鍵交換アルゴリズムで生成されたあたいは、さらにサーバ証明書の秘密鍵で暗号化され、公開鍵で復号されるんですね。で、真正性を確かめるんですよね。 ここ、知らんかった。すごく大事。 ただ覚えておきたいのが、RSAを用いた鍵交換では、署名がなされないということ。証明書の公開鍵は、クライアントが生成したプリマスターシークレットを暗号化するために使われる。そして、秘密鍵で復号するんだよね。 ECDHEでは、毎回公開鍵が生成されるんだよね。で、その公開鍵の正当性を証明するために秘密鍵で署名し、公開鍵で検証するんだよね。 RSAを用いた鍵交換では毎回同じ公開鍵と秘密鍵のペアで通信がなされるんだよね。プリマスターシクレットも含めてね。 だから、スノーデン事件の時みたいに、暗号化されたものをずっと溜めておいて、後でどうにか秘密鍵を入手して、プリマスターシクレットを特定、 からの通信内容を特定、といったことができてしまうんだよね。これ、前方特秘性がないって言いますね。 これに対して、ECDHE、DHEは、一回一回秘密鍵と公開鍵を生成するんだよね。はいそうだね。 でも、公開鍵から秘密鍵は、頑張れば何年かかければ、推測可能だよね？だから前方特秘性は、ないと思うんだけど。 これをchatGPTに聞いてみたらこう帰ってきました。 Q. 離散対数問題は時間をかければ解読可能です。各セッションで使われる公開鍵から秘密鍵を割り出すことも、原理上は可能です。 そこで、各セッションの公開鍵と、暗号化された通信全てを保存している人がいたとしましょう。そうすると、時間さえかければ、暗号文を解読できると思うのですがいかがでしょう。 ...