楽天が公開サーバーにテキスト設置、セキュリティー向上に役立つ「security.txt」
楽天グループが2023年10月2日、Webサーバーにsecurity.txtを設置し、脆弱性情報の受付窓口としてVDP（脆弱性開示プログラム）を開始したことがSNSで話題になった。同社広報はこれを事実だと認めた。 日本有数のIT企業である楽天グループが「Webサーバーにテキストファイルを設置？」「脆弱性情報の受け付けがなぜ関係するの」と思った人もいるだろう。このsecurity.txtは、米Apple（アップル）や米Google（グーグル）、米GitHub（ギットハブ）、米IBMなど、IT関連の製品やサービスを提供する海外企業はすでに導入しているものだ。 一方、国内企業でsecurity.txtを導入している企業は少ない。security.txtとは何か、脆弱性情報の受け付けとの関連性、国内企業ではなぜ普及していないのか、順番に見ていこう。 security.txtがセキュリティー向上につ
TLS 1.3の標準化と実装 | IIJ Engineers Blog
IIJ-II 技術研究所 技術開発室の山本です。現在技術開発室は、私を含めた4人で構成されており、主にプログラミング言語Haskellを使って開発を進めています。今回の話題である TLS(Transport Layer Security) 1.3 もHaskellで実装しました。 4年の歳月をかけて議論されてきたTLS 1.3ですが、この8月にめでたく仕様がRFC 8446となりました。貢献者リストに私の名前が載っていることを聞きつけた広報から、ブログ記事の執筆依頼がありましたので、TLS 1.3の標準化や実装の話について書いてみます。 なぜTLS 1.3を標準化する必要があったのか理由を知りたい方は、「TLSの動向」という記事や「TLS 1.3」というスライドを読んで下さい。 インターネットで使われているプロトコルは、IETFという団体で仕様が議論されて策定されます。IETFには、誰でも
なぜTheo de RaadtはIETFに激怒しているのか
本の虫: OpenBSD、怒りのコミットで、OpenBSDのTheo de RaadtがIETFに対して激怒している。 src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 なぜTheo de Raadtは、OpenSSLではなく、IETFに対して激怒しているのか。IETFというのは、インターネット上の規格制定の団体である。今回、世上を騒がせているHeartbeat問題は
DNS RFC系統図
1. 1 2012-‐‑‒11-‐‑‒21 DNSOPS.JP BoF DNS RFC系統図 -‐‑‒ DNS Summer Days 2012 -‐‑‒ DNSのRFCの歩き⽅方 – の宿題 – 株式会社ハートビーツ 滝澤隆史 ⽇日本Unboundユーザー会 2. 2 私は誰 • ⽒氏名: 滝澤 隆史 @ttkzw • 所属: 株式会社ハートビーツ ▫ サーバの構築・運⽤用や 24時間365⽇日の有⼈人監視をやっている会社 ▫ いわゆるMSP（マネージド サービス プロバイダ） • DNSとの関わり ▫ システム管理理者として1997年年から2006年年までネームサー バの運⽤用 – BIND4, BIND8, djbdns, BIND9 ▫ 現在は個⼈人サーバでネームサーバを運⽤用 – NSD, Unbound
Pretty RFC
The RFC is now diamonds RFCs are documents produced by The Internet Engineering Task Force, and many are official standards for various Internet protocols. This site indexes and formats these documents for easier finding & viewing. Note: most RFCs can't be prettified at the moment, as their source files are unavailable to the public and need to be requested from rfc-editor.org. I'm working on this
yebo blog: エイプリルフールのジョークRFC
2009/04/02 エイプリルフールのジョークRFC エイプリルフールには必ず四月馬鹿RFCが発行される。今回は、"IANA Considerations for Three Letter Acronyms" (RFC 5513) と "IPv6 over Social Network" (RFC 5514)の二つ。RFC 5513は、IANAが3文字略語(TLAs: Three Letter Acryonyms)増えてきて、誤解による混乱が生じているので、登録管理を検討しているというもの。RFC 5514は、ソーシャルネットワーキングのプラットフォームをIPv6ネットワークに移行することで、IPv6接続ホスト数を増やそうという提案。IPv6も冗句ネタになるほど落ちぶれてしまったか :-) 投稿者 zubora 投稿時間 17:16 ラベル: Funny, Protocol 0 コメント
JPNIC News & Views vol.536【臨時号】 - JPNIC
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ __ /Ｐ▲ ◆ JPNIC News & Views vol.536【臨時号】2008.4.9 ◆ _/ＮＩＣ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ◆ News & Views vol.536 です ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 本号では、vol.532、vol.534、vol.535に続き、第71回IETFのレポート[第4弾] として、セキュリティ関連WGの動向についてお届けします。 □第71回IETF報告 特集 ○[第1弾] 全体会議報告 (vol.532) http://www.nic.ad.jp/ja/mailmagazine/backnumber/2008/v
PKCSとRFCの一覧 - しいしせねっと
全然読んでないけど… PKCS #1 v2.2、PKCS #5 v2.1からはIETF管理下へ? PKCS #1 RSA 暗号、署名 RSASSA-PKCS1 RSASSA-xxx PKCS #5 パスワード拡張、暗号 PBES1 PBES2 PBKDF1 PBKDF2 PBMAC1 PKCS #7 -> CMS RFC 3370 Cryptographic Message Syntax (CMS) Algotithms RFC 3369 -> 3852 CMS main -> 5652 RFC 5083 CMS Authenticatied-Enveloped-Data Content Type RFC 5084 Using AES-CCM and AES-GCM Authenticated Encryption in CMS RFC 5911 PKCS #8 PKCS 秘密鍵のASN.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
yebo blog: RFC 6164: Using 127-Bit IPv6 Prefixes on Inter-Router Links
Document Search
HTTPの仕様が改定される