こちらは改訂前の旧版のページです。改題第2版の商品ページをご覧ください Webセキュリティ解説の決定版 "Bulletproof SSL and TLS" の全訳(原書2017年版へのアップグレード済み) Ivan Ristić 著、齋藤孝道 監訳 520ページ B5判 ISBN:978-4-908686-00-9 電子書籍の形式:PDF 2020年7月4日 第1版第5刷 発行(原書2017年版アップグレード対応済み) 本サイトにてユーザ登録のうえ購入いただくと、原著改訂第2版に収録されるTLS 1.3の解説章を付録として含んだ特別版PDFがお読みいただけます 現代生活を支えるネットワークにとって、通信の暗号化は不可欠の機能です。しかし、実際のインターネットで暗号化通信を利用できるようにするには、暗号化アルゴリズムの知識だけでなく、セキュリティプロトコルとその実装技術、さらに、基盤となる信
前回と前々回では、Windowsネットワークを支えるトランスポート層プロトコルであるTCP/IPとNetBIOS(NetBEUI)プロトコルについて見てきた。今回はWindowsネットワークにおけるファイル共有プロトコルのSMB/CIFSの概要について見ていく。 Windowsネットワークにおけるファイル共有プロトコルの歴史 Windows OSにおけるファイル共有プロトコルは、正式には「SMB(Server Message Block)」もしくは「CIFS(Common Internet File System)」という(SMBとCIFSの違いについては後述)。歴史的な経緯によってSMBと呼ばれたり、CIFSと呼ばれたりしているが、現在ではSMBが正式な名称とされている。 SMBは、もともとはLAN ManagerというネットワークOS(OS/2ベースのファイルサーバーOS)などで動作し
2014-09-28 rsyslogでリモートサーバにログを送る(基本編) サーバ Linux syslog 前回、rsyslogの特徴を整理した。 今回はこれを踏まえてログをリモートサーバに送る基本的な設定をしてみたいと思う。 以下のような構成です。本日のゴールは以下の2点 クライアントからリモートサーバへログ転送する TCP,UDPの両プロトコルで転送する 内容としては基本的ですが、一歩ずつ進める方針。 ファシリティ、プライオリティ、保存先ファイルの設定については プロトコル別に分けてこんなかんじで。 TCP -> local1.* /var/log/local1.log UDP -> local2.* /var/log/local2.log サーバの設定まずサーバ側の設定。/etc/rsyslog.conf (前略) #### MODULES #### $ModLoad im
ADSLが登場する2000年ごろよりも前のインターネット接続といえば、自宅のモデムから契約しているプロバイダが用意しているアクセスポイントにダイヤルして電話回線で接続する「ダイヤルアップ接続」が圧倒的に主流を占めていました。ダイヤルアップでの接続時にモデムから聞こえる「ピーーーゴーーーザーーーー」という音を覚えている人もいると思いますが、そんなダイヤルアップ接続音をグラフで可視化し、それぞれの音の役目を目に見える形で表した画像が公開されています。 absorptions: The sound of the dialup, pictured http://www.windytan.com/2012/11/the-sound-of-dialup-pictured.html ダイヤルアップ接続音を聞いたことがない人は下記ムービーから確認可能です。 The Sound of dial-up Int
1. はじめに、 昨日 OpenSSLのバージョンアップがアナウンスされ、9つの脆弱性が公開されました。バージョンアップの数日前にOpenSSLの次期リリース予告がアナウンスされていましたが、ちょうど BlackHat 開催初日にあたることもあり、なんかまた重大な脆弱性の修正が入るんじゃないかとドキドキしていました。蓋を開けてみるとHeatBleed程の大事ではなくホットひと安心です。 昨日公開されたOpenSSLの9つの脆弱性のうち、TLS プロトコルダウングレード攻撃 (CVE-2014-3511)の修正を見ていたところ、これはTLSプロトコルを学ぶいい題材になるなぁとふと思いつき、試しにこのOpensslの脆弱性の詳細をTLSプロトコルの基礎に合わせて書いてみました。 ちょっと長いですが、TLSプロトコルの仕組み(の一部)を知りたい方はお読みください。 2. OpenSSLの脆弱性
OpenSSLのheatbeatバグの対応のため、OpenBSDはOpenSSLのheatbeatを無効にするコミットをした。ただし・・・ src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 このコミットは、Makefileの中で、OpenSSLでheatbeatを無効にするマクロを定義するよう、コンパイラーオプションを指定するものだ。ただし、無効にするマクロは、OPE
SR-IOV (1) (2) (3) (4) InfiniBand (1) SMB Multichannel (1) (2) (3) 前回 の最後にも少し触れたとおり、今回は「SMB マルチチャネル」について。 SMB Multichannel は Windows Server 2012 からの新機能で、 SMB トラフィックのロードバランスや帯域増強、パス障害に対応するマルチパス技術です。“NIC チーミングの SMB/CIFS プロトコル限定版”と言えばイメージしやすいかもしれません。 デフォルト設定は On。つまり、デフォルトでは通信相手に対して SMB の通信パスが複数ある場合、そのすべてのパスが自動的に使われます。 Multichannel の特徴 Multichannel は SMB/CIFS プロトコルに限定で、しかもマルチホーム。 更にパス障害時の切り離しが遅い。。。 良い
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて3つに分けられるかと思う(私の勝手なイメージ、正確な図ではありません) Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く