イラストで正しく理解するTLS 1.3の暗号技術
イラストで正しく理解するTLS 1.3の暗号技術 初めに ここではTLS 1.3（以下TLSと略記）で使われている暗号技術を解説します。 主眼はTLSのプロトコルではなく、「暗号技術」の用語の挙動（何を入力して何を出力するのか）と目的の理解です。 実際にどのような方式なのかといった、より詳しい説明は拙著『図解即戦力 暗号と認証のしくみと理論がこれ1冊でしっかりわかる教科書』（暗認本）や『暗認本』の内容を紹介したスライドや動画などの資料集をごらんください。 なお表題の「イラストで」は数式を使わないという程度の意味です。 TLSで守りたいもの TLSはコンピュータ同士が安全に通信するための規格です。 主に人がブラウザを介して「https://」で始まるWebサイトにアクセスするときに利用されます。 安全に通信するためには、通信内容が盗聴されても情報が漏れない機密性が必要です。 それから通信が改
Firefoxは危険なJavaScriptに対応しない - Qiita
Firefox / Safari MozillaはMozilla Specification Positionsというリストを公開しています。 IETFやW3C、TC39などが提唱しているWeb技術に対して、Mozillaはどのように評価しているかという立ち位置を表明したものです。 あくまで現時点での評価であり、もちろん今後の仕様変更などに伴い評価は変わる可能性があります。 Mozilla's Positions Mozillaはどのように評価しているかの分類。 under consideration 評価の検討中。 important 優れた概念であり、Mozillaにとっても重要である。 worth prototyping 優れた概念であるが、プロトタイプを作成し、フィードバックを得て磨きをかける必要がある。 non-harmful 有害ではないが、良いアプローチではなく、取り組む価値
Secure Remote Password プロトコル Ruby デモ - Tociyuki::Diary
Secure Remote Password プロトコル (略号は SRP) 総本山のサイト http://srp.stanford.edu/ で公開されている Javascript による SRP-6a のオンライン・デモ http://srp.stanford.edu/demo/ を Ruby に訳してみました。モジュラスは1024ビットのみに対応しています。 ⇒ https://gist.github.com/790048 SRP-6a の特徴は以下の通りで、Diffie-Hellman 鍵交換に似た数学モデルを使って一連のチャレンジ・レスポンスをおこないます。 ユーザ名 username と共通鍵である平文パスワード password を使って、クライアントとサーバ間でユーザ認証をおこなうプロトコルである。 サーバは平文パスワードをサーバは保存しない。ハッシュ値から求めた巨大整数を
SRP: Industry-Standard Strong Password Security
The Stanford SRP Homepage The Secure Remote Password protocol performs secure remote authentication of short human-memorizable passwords and resists both passive and active network attacks. Because SRP offers this unique combination of password security, user convenience, and freedom from restrictive licenses, it is the most widely standardized protocol of its type, and as a result is being used b
SmartHRにおけるAWS WAF運用術 - SmartHR Tech Blog
こんにちは、セキュリティエンジニアの岩田です。SmartHRではサービスを保護するためAWS WAFを利用しています。今回はSmartHRにおけるAWS WAFの運用事例をご紹介したいと思います。 AWS WAFとは? AWS WAFはWebアプリケーションの脆弱性への攻撃を検知・ブロックする、Webアプリケーションファイアウォールのサービスです。 現在、AWS WAFには AWS WAF v2 AWS WAF Classic の2種類があります。 SmartHRではv2のリリース以前からAWS WAFを使用しており、まだv2への移行は行っていないため、以下で記載する内容は全てAWS WAF Classicのものになります。AWS WAF v2では該当しない事項もあるかもしれませんので、ご了承ください。 構成 リソースの構成 AWS WAFに関連するリソースの構成と処理の概要は以下の通りで
iOSアプリ内で不正なSSL証明書を検知する / SSL Pinning for iOS apps
iOSDC Japan 2018 8/31 14:20~14:50 @Track A Ask The Speakerでの質問と回答を追記しました
SMSで送信元を偽装したメッセージを送る
送信元表記が送信者IDのケース SMSのメッセージを受信した際に表示される送信元には、電話番号の代わりに任意の英数字も表記できる。この英数字の送信元表記を「送信者ID（Sender ID）」という。JC3の図では 通信事業者Ａ が送信者IDに当たる。 なお送信者IDの利用可否は受信側の通信事業者の対応状況によって異なる。Twilioの販売パートナーであるKWCの説明によると、日本国内ではNTT DOCOMOとSoftBankが送信者IDに対応し、KDDIは対応していないとのこと²。私はKDDIの回線を所有していないため、受信側がKDDIの電話番号を使用している場合の挙動は検証できていない。 まずはiOSの公式メッセージアプリに届いていたAmazonからのメッセージのスレッドで偽装を試みる。送信者IDは Amazon となっているため、TwilioでSMSを送信する際のFromの値に Ama
最近のやられアプリを試してみた
乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）
マルウェア解析に必要な素養 - HackMD
本書は、マルウェアが絡んだ事情を体系的にまとめている。攻撃者、防衛者、解析者の各視点から"マルウェア"のチョメチョメを理解することを目標としている。
「二段階認証…？」と言わないためのMFA入門 --- あるいはIDシステム地獄への案内 - ブログなんだよもん
はじめに さて、7 Payの社長が2段階認証知らなかった問題が良い感じに炎上していますね。 個人的には常に知っておく必要が絶対あるかというと専門分野の問題があるから議論の余地あるとして、セキュリティの問題で会見するなら部下にちゃんとレクさせろよ、とは思う。 7 PayとMFAの話は下記の動画でも話したんですが、7 Pay云々は忘れて「そもそもMFAってなに？」ってところをもう少し整理してまとめていきたいと思います。 www.youtube.com 認証と認可 まずはおきまりの「認証(Authentication)」と「認可(Authorization)」の違いです。 日本語で書いても英語で書いてもややこしいのですが、「認証」とは「Identify」すなわち誰であるかの確認です。対して「認可」は「Access Control」すなわち誰に何をさせる事を許可するか、という事です。 基本的にはM
DNS over TLS/HTTPSについて考える | IIJ Engineers Blog
はじめに 昨年から DNS over TLS （DoT）、DNS over HTTPS （DoH） にまつわる動きが急速に活発になっています。 DoT は2016年に RFC7858 が出てしばらくは大きな動きはありませんでしたが、2017年11月にサービス開始した public DNS である Quad9 （9.9.9.9）、昨年4月開始の Cloudflare （1.1.1.1）が相次いで DoT に正式対応し、遅れて今年1月には Google Public DNS （8.8.8.8） も対応しました。クライアント側としては昨年8月リリースの Android 9 “Pie” が DoT に対応しています。 DoH は仕様の標準化より実装の方が先行しています。Cloudflare は DoT だけでなく DoH も昨年4月のサービス開始当初からサポートしています。Mozilla Fire
政府によるインターネットの検閲とSNIについて
しかし今回一般の人の目にも触れる形でSNIやHTTPSのことが報じられた結果、エンジニアも含めて明らかに技術に関して勘違いをしているのではないかと感じる発言を見ることがありました。このまま放置するのも良くないと感じているので、Q&Aという形でSNIやHTTPSに関する誤解を少しでも解ければと思います。 Q&AQ: そもそもSNIって何？以前書いた記事にも書かれているので是非読んでみてください。 簡単に説明すると、HTTPSではSSL/TLSを利用して通信が暗号化されます。なので1つのIPアドレスで複数の証明書を扱おうとした場合、最初の通信時にどの証明書を利用すればいいか分かりません。そこでSNIが必要になります。 SNIは最初の通信時に今から通信したいサーバーネーム（ドメイン名と考えてください）をサーバーに平文で渡すことで、通信したいSSL証明書を指定できます。SNIは現在の一般的なブラウ
.appという画期的でセキュアなgTLDについて - Lento con forza
.appというgTLDをご存知でしょうか。gTLDはgeneric top-level domainの略後で、ICANNが管理しているトップレベルドメインのことです。 有名どころでは.comや.net等があります。このブログのURLは https://kouki.hatenadiary.com ですが、この.comの部分がトップレベルドメインです。*1 このトップレベルドメインはICANNという組織が管理しています。2012年までは限られたトップレベルドメインしか存在しませんでしたが、2012年の公募では基準を定め、その基準を満たした団体は自由にgTLDを作ることができるようになりました。これ以降大量のトップレベルドメインが登録され、今では様々なドメインを利用することができます。 その中の一つ、appドメインが去年話題を呼びました。 appドメインはセキュアなドメイン そんなappドメイン
リンクを作る時の target="_blank" の危険性 - 隙あらば寝る
html で リンクを新しいタブ(やウィンドウ)で開かせたい場合、target="_blank" を指定するが、 この使い方には落とし穴があるらしい。 www.jitbit.com リンクを開いた先の javascript から、開いた元のページを操作できてしまうとのこと。 気になったので確認してみた。 悪用のパターン insecure.html が最初に開くページで、ここに target="_blank" なリンクがある。 このリンクを押すと new_window.html を新しいタブで開く。 この new_window.html に javascript が仕込まれており、元ページを操作されるという話。 具体的には window.opener.location="./evil.html" と実行すると、元タブは evil.html に遷移する。 実際試してみたのが ここ。 リンクを開
Webデバイストラッキング手法の紹介
サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで / How Snowflake Is Used In CyberAgent - Go To the Future
徳丸浩の日記: SSRF(Server Side Request Forgery)徹底入門
SSRF(Server Side Request Forgery)という脆弱性ないし攻撃手法が最近注目されています。以下は、ここ3ヶ月にSSRFについて言及された記事です。 EC2上のAWS CLIで使われている169.254について SSRF脆弱性を利用したGCE/GKEインスタンスへの攻撃例 SSRFを利用したメール送信ドメインの乗っ取り 「CODE BLUE 2018」参加レポート（岩間編） この「空前のSSRFブーム」に便乗して、SSRFという攻撃手法および脆弱性について説明します。 SSRF攻撃とは SSRF攻撃とは、攻撃者から直接到達できないサーバーに対する攻撃手法の一種です。下図にSSRF攻撃の様子を示します。 攻撃者からは、公開サーバー（203.0.113.2）にはアクセスできますが、内部のサーバー（192.168.0.5）はファイアウォールで隔離されているため外部から直接
どうして JWT をセッションに使っちゃうわけ？ - co3k.org
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ？」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
20分でわかるgVisor入門
2018年5月28日開催 『Container SIG 2018 Summer』のスライド資料です。Read less
HTTP/2, QUICからTLS1.3へ
HTTP/2, QUICからTLS1.3へ 大津 繁樹 株式会社インターネットイニシアティブ(IIJ) Internet Week 2015 2015/11/18 2015年11月19日更新版 自己紹介 • 大津 繁樹 • 株式会社 インターネットイニシアティブ(IIJ) • プロダクト本部 アプリケーション開発部サービス開発2課 • Node.JS Technical Steering Committee メンバー • (主にTLS/CRYPTO/OpenSSLバインディングを担当） • IETF httpbis WG で HTTP/2相互接続試験等仕様策定に参画。しかし TLS1.3の標準策定作業にはこれまで直接かかわっていません。 • ブログ： http://d.hatena.ne.jp/jovi0608/ でTLS周りのネタをいろいろ 書いています。 内容 現在仕様策定作業中のTL
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
