タグ

ブックマーク / d.nekoruri.jp (4)

  • パスポートと公開鍵の議論ポイント - めもおきば

    www.osstech.co.jp この記事をきっかけに公開鍵暗号やPKIの在り方について議論が盛り上がってるので、ポイントになりそうな話をまとめてみます。 パスポートにおける公開鍵暗号のおさらい 上の記事を読んでください、という感じなのですが、ざっくりまとめると以下の仕組みです。 ・ICカードにアクセスするためのBasic Access Control:いわゆるPINとかに相当します。「パスポート番号 + 生年月日 + パスポートの有効期限」とのことなので、要するにパスポートの顔写真のページを見た人ならば分かる情報です。 ・データの電子署名を確認するPassive Authentication:Basic Access Controlを通ると、券面のデータ及び、そのハッシュ値:SOD(Security Obeject Document)、SODに対する電子署名が取得できます。この電子署名

    パスポートと公開鍵の議論ポイント - めもおきば
    rryu
    rryu 2019/04/25
    拒否理由が真正性を担保できない方法で外務省から送付することはできないなら納得はできる。その上でICAO PKDのマスタリストから取ってほしいと案内があればよかった。
  • glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば

    RHEL, CentOS, Amazon Linux (6以前) /etc/localtime を /usr/share/zoneinfo 以下から上書きしたりシンボリックリンク張ったりという手法が横行していますが、 /etc/localtime は glibc パッケージに含まれるためパッケージを更新すると上書きされてESTとかに戻ってしまうわけです。 当然ながら、ディストリビューションとして正しい設定方法が用意されているので、こちらを使います。 /etc/sysconfig/clock にタイムゾーンを書きます。*1sudo sed -i -e "s/^ZONE/#ZONE/g" -e "1i ZONE=\"Asia/Tokyo\"" /etc/sysconfig/clock tzdata-update を実行します。sudo /usr/sbin/tzdata-update これだけで

    glibcを更新しても大丈夫な「正しい」タイムゾーンの設定方法 (2/3追記あり) - めもおきば
    rryu
    rryu 2015/02/02
    Apacheの管理方法といい、ああいう類のドキュメントってどこにあるんだろう。
  • ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば

    条件1. /bin/shの実体がbashのディストリビューション RHEL CentOS Scientific Linux Fedora Amazon Linux openSUSE Arch Linux (自ら設定した場合: Debian, Ubuntu) 条件2. 動作環境 CGI (レンタルサーバでありがちなCGIモードのPHP等も含む) Passenger(Ruby) 条件3. プログラム内容 Passengerは全死亡 *1 systemや `command`、 '| /usr/lib/sendmail' などで外部コマンド実行 *2 PHPのmailやmb_send_mail、その他フレームワーク等を介したメール送信 *3 以下は条件1が不要 明示的にbashを呼ぶ 先頭で #!/bin/bash や #!/usr/bin/env bash しているプログラムを実行 (rbenv

    ウェブアプリにおけるBash脆弱性の即死条件 #ShellShock - めもおきば
    rryu
    rryu 2014/09/28
    PassengerLoadShellEnvvarsがONだとワーカーをシェル経由で起動するので即死ということらしい。そしてデフォルトはON……
  • CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば

    必要な情報は http://heartbleed.com/ にまとまっているのですが、英語だし長いしって人のために手短にまとめておきます。 どうすればいいのか OpenSSL 1.0.1〜1.0.1fを使っていなければセーフ あてはまる場合には、一刻も早くバージョンアップして、サーバごと再起動(わかるひとはサービス単位でもOK、ただしreloadではだめなことも) SSL証明書でサーバを公開しているなら、秘密鍵から作り直して証明書を再発行し、過去の証明書を失効させる(末尾に関連リンクあり)。 サーバを公開していない場合も、外部へのSSL通信があれば影響を受けるので、詳しく精査する。 PFS(perfect forward secrecy)を利用していない場合、過去の通信内容も復号される可能性があるため、詳しく精査する。 漏洩する情報の具体例は、OpenSSLの脆弱性で想定されるリスクとして

    CVE-2014-0160 OpenSSL Heartbleed 脆弱性まとめ - めもおきば
    rryu
    rryu 2014/04/09
    対応済みパッケージのバージョン一覧があってすばらしい。
  • 1