はてなキーワード: SSLとは
http://developers.linecorp.com/blog/ja/?p=3591
Letter Sealing って何でしょうか。私気になります。
必要な範囲で、原文を引用しています。原文は先に引用元のアドレスと閲覧日時を記し、引用記法によって地の文と識別できるようにしています。
ECDHとAES256-CBC 使ってみた。通信相手の認証については読み取れない。
図2 において、 Server のところで Re-Encryption (一度復号されて、再度暗号化されている) ことが明示されています。
この図を素直に読むと、送信者からサーバーまでの通信路は暗号化されているものの LINE のサーバーが受信したところで復号されて平文で保存され、サーバーから受信者までの通信路は暗号化されていると理解できます。文脈から、この流れを変えたいのであると推測できます。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧:
加えて、LINEでは、仮に通信ネットワークの傍受が行われたとしてもメッセージを覗くことができないように、公開鍵暗号(public key encryption)方式を使っています。ユーザーに対してLINEアプリを提供する際、暗号化ができる公開鍵のみをアプリに入れて提供し、ユーザー端末とサーバが接続されたときだけLINEサーバでのみ解析できる暗号化された安全なチャネルを作ります。こうすることで、SSL(Secure Socket Layer)より軽く、LINEの全バージョンで使用できる安全な暗号化を実現できます。
SSL はすでに時代遅れの代物で、 2015年秋現在は皆さん TLS を利用されていることでしょう。 Web ブラウザで SSL 2.0 や SSL 3.0 を有効にしているそこのあなた、今すぐ無効にしましょう。
TLS では、公開鍵暗号方式や共通鍵暗号方式、電子証明書、暗号学的ハッシュ関数といった複数の暗号技術要素を組み合わせて安全な通信路を確保しています。
RSA に代表される公開鍵暗号方式は一般的に AES に代表される共通鍵暗号方式と比べて計算量が大きい、つまり重たい処理となります。
このため TLS では、通信路を流れるデータの暗号化に共通鍵暗号を用いて、共通鍵の共有や相手の認証のために公開鍵暗号方式を用いるのが一般的です。
仮にメッセージの暗号化に RSA を用いているとしたら、 SSL より軽いという点をどのように実装しているのか気になります。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧:
ユーザー側のLINEアプリ(クライアント)には、サーバが発行したRSA鍵を使用してデータの暗号化に使う暗号化鍵値を共有します。この鍵を利用してデータを暗号化すると、第三者はメッセージを見ることができなくなります。
これは上で説明したとおり SSL や TLS でも行っていることです。
RSA を用いているので安全であるという主張をしていますが、メッセージの暗号化に用いられている暗号スイート(アルゴリズムの種類、鍵の長さ、ブロック暗号の場合は暗号利用モード、そしてハッシュアルゴリズムの種類)は、その通信路が安全であると判断できるか否かを決める大切な情報です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧:
既存のRSA方式も秘密データの共有に使う安全な方式ではありますが、鍵管理の面から見ると、ユーザー側の端末でそれぞれのRSA鍵をすべて管理しなければならないという問題があり、その代替手段としてDHを使用するようになりました。
DH および ECDH による共通鍵暗号に用いる鍵の交換は SSL や TLS でも実装されており近年では広く使われています。 SSL より軽いと主張し、 SSL や TLS が公開鍵暗号方式以外の要素によって担保している安全性をどのように確保しているか不明な実装に比べると、大きな改善です。
なお SSL や TLS においては通信相手の公開鍵を全て管理する必要がないように、上で説明した電子証明書による公開鍵基盤 (PKI) の仕組みを利用しています。
つまり共通鍵暗号に用いる鍵の交換にどのような手段を用いるかは、鍵管理とは(ほぼ)独立です。
http://developers.linecorp.com/blog/ja/?p=3591 より引用、2015年10月14日 22時40分に閲覧:
ここでメッセージの暗号化に使用している暗号化アルゴリズムはAES-CBC-256という方式で、現在一般に使われている暗号化アルゴリズムの中で最も強度が高いと評価されています。
メッセージ認証と組み合わせない CBC はビット反転攻撃に弱いことが知られています。 GCM ではデータの暗号化と認証を同時に行うためビット反転攻撃に耐性があります。 AESを GCM で利用するのは、 最近の TLS の実装では広く用いられており、 Google や twitter も利用しています。
CBC も CBC-MAC のようにメッセージ認証と組み合わせることでビット反転攻撃に強くなります。
図6 のとおり、 ECDH で共通鍵暗号に用いる鍵の交換を行うにしても通信相手の公開鍵は必要です。 上で説明したとおり鍵管理という問題への解決策になりません。また公開鍵が本当に通信相手のものであることをどのように検証するのかについても不明です。通信相手の検証は、送信側では秘密の話を他の人に知られないように、受信側では他の人になりすまされないように、双方にて必要です。
ここからは安易なパターンの想像ですが、通信相手の公開鍵情報は LINE ユーザー情報の一部として LINE サーバーで管理されており、必要に応じて安全な通信路を用いて LINE サーバーから取得するようなものではないかと思います。公開鍵情報のやりとりに用いられる通信路に正しく実装された TLS が用いられていて、サーバーとクライアントの両方が認証されていて、現在の水準から見て妥当なレベルの暗号スイートが用いられていることを願うばかりです。
公開鍵と秘密鍵がどこでどのように保管されているのか気になります。各端末で保管するのが安全ですが、サービスの要求として端末を乗り換えてもメッセージが読めるという条件を安易に満たすために秘密鍵を LINE サーバーに預託していないことを祈るばかりです。
ECDH 鍵の生成は計算量が大きい処理であり質の良い乱数を必要とします。 PC に比べると非力なスマートフォンで生成した鍵の質をどのように担保しているのか気になります。
先ほど閲覧したところ、上記引用箇所の多くは削除されていました。公開鍵が本当に通信相手のものであることをどのように検証するのかについては明らかではないようです。 LINE サーバーが介在する形であれば、鍵をすり替えることで別のユーザーになりすますことが可能でしょう。または、 LINE アプリに何か細工をする方がより簡単でしょう。
ECDH 鍵はその場限り (ephemeral) という説明がないので Perfect Forward Secrecy ではないと考えられ、望ましくないという意見もあるようです。 LINE サーバーとの間に安全な通信路を確立する目的で ECDH 鍵を用いる場合、 LINE サーバーが用いる秘密鍵の漏洩は全てのユーザーに影響を与えうるため PFS は非常に重要です (TLS を用いた Web サーバーでも同様です) 。一方ユーザー間でメッセージを暗号化する場合、ユーザー所有の ECDH 鍵についてはそのユーザーに影響が限定されます。通信相手ごとに必要なその場限りの鍵生成とユーザー所有の ECDH 鍵を利用した鍵交換にかかる計算量と ECDH 鍵漏洩のリスクを天秤にかけて PFS を採用しないという判断かもしれません。
通信の秘密という観点ではメッセージの内容だけではなく誰と通信したか (または、していないか) という情報も守りたくなります。宛先を LINE サーバーで確認できない形に暗号化されるとメッセージの配送ができなくなるため、通信相手や通信の有無については秘密ではないと考えられます。
一般的に外に出るために HTTP proxy 他を経由する必要があってしかも HTTP と HTTPS くらいしか通らないし、443/tcp で ssh を上げても proxy で弾かれるみたいなネットワークが存在する。
そんな場合に良く使われる proxytunnel(http://proxytunnel.sourceforge.net/) というソフトがあり、 Apache を SSL で HTTP proxy としても動作させて特定の ssh 等の port に接続させることで SSH over HTTPS を実現することが出来る。(proxytunnel で HTTP proxy を二段経由させた後で SSH に接続する)
ただし Apache2.2 では SSL での HTTP proxy の動作にバグがあり、上記を実現するために proxytunnel 用のパッチを適用しておく必要があった。(https://bz.apache.org/bugzilla/show_bug.cgi?id=29744)
このバグは Apache2.4 において修正されている筈なのであるが、何故か Windows の proxytunnel で接続出来ないという現象が起こったのでその対処法を書いて置こうと思う。
proxytunnel の最新版は上のページの通り 1.9.0 で Windows 用のcygwinビルドもあるのであるが、
Debianなどのパッケージでは 1.9.0+svn250-5 までバージョンが上がっている(https://packages.debian.org/ja/jessie/proxytunnel)
そしてこの 1.9.0+svn250-5 だとパッチ無しの Apache2.4 で問題なく動作するのだ。
なのでこの 1.9.0+svn250-5 のソースを持って来て cygwin 環境で Windows 用にビルドするのが解決策となる。
cygwin でのビルド自体はライブラリが揃っていることと、manページの生成でエラーが出るので本体のビルドだけにしておいた方が良いこと以外はとくに特殊なことは無かった。
配信停止依頼しようにもドメインがデタラメでたぶん単純な返信メールには応じなさそうだし、
配信停止依頼にはこちらのメールアドレスを晒してメールを送らないといけないので、晒しておきますね。
※特商法ではありません
http://dkij2.b3qzt.com/special.php?special=3&s=1441443363&code=def&ssl=1441443363&ssl=1441443363
《運営者》
dkij2.b3qzt.com事務局
《メールアドレス》
info@dkij2.b3qzt.com
http://gigazine.net/news/20150718-present-summer-2015/
当選者発表の期日過ぎてもGIGAZINEから連絡は無いから当たり前のようにプレゼントはハズレ(というか応募忘れてた)。
その代わり、「GIGAZINEシークレットクラブ 無料体験コード」なるものが届いた。
GIGAZINEシークレットクラブ は、まあ簡単に言うとGIGAZINEをもっと便利に使えますよ、有料だけど。というやつで、
そういや応募時のアンケートにそんなのあったなーと思って試しに使ってみたんですよ。
http://webbingstudio.com/weblog/cms/entry-773.html
小規模の商用サイトでは、フォームを暗号化する際には、共有SSLを利用するのが当たり前となっています。独自ドメインのSSL証明書を取得すると、フォームを通して得られる収益よりも、維持費の方がはるかに高くなってしまうからです。
とこの記事では書かれていますが、一体どこで「当たり前」なんでしょうか?
SSL証明書の取得費用は、サーバーホスティングによって額がまちまちなのは確かですけれども、
安く独自SSL証明書を取得して利用できるサーバーホスティングは山ほどあります。
WEB制作者として「自分が良く知っているだけ」のサーバーのレンタルをクライアントに押し付けてはいませんか?
また、小規模商用サイトにしても、仮に年額35,000円のSSL証明書をつけ、かつ、月額3,000円のサーバーを借りていたとすると
月額でいえば6,000円くらいの負担ですが、
いくら小規模とはいえ、広報活動の中核をなすWEBサイトであるならば、
月額6,000円をペイできないとすると、
(というか、効果測定をしていないだけ?)
共用SSLのリスクに関して言えば、この記事が引用している、高木浩光氏の書かれている通りではあります。
cookieが取得できてしまう結果として、一番最初に狙われるのは、管理画面へのログイン。
いわゆるセッションハイジャックです。
ログイン状態を乗っ取られた時点で、どんなCMSでも、WEBサイトの改ざんは可能です。
なぜか。
そのコンテンツは多くの場合MySQLに代表されるDBに保存してあります。
したがって、ファイルの改ざんなどを行わずとも、WEBサイトの内容は書き換えることが可能なのです。
「なるほど」と思ってしまうかもしれないので、
早々に訂正していただきたい。
また、この記事にある a-blog cmsというCMSについてはよく知りませんが、
多くのモダンなCMSでは、ほとんどの管理画面ログインにおいて、
セッションハイジャックに対する防衛は行われていますので、
cookieの取得が、即WEBページの改ざんに繋がるような書き方も、
ここも早々に訂正していただきたい。
この筆者さんは、a-blog cmsというCMSを利用されているようだ。
このCMSはどうやら、PHP製ながらPHPのソースを暗号化しているようだ。
こう言ってはなんですが、攻撃者にしてみれば、a-blog cmsを攻略するくらいならMovable TypeやWordPressを攻めた方が楽というものです。
この記述はむちゃくちゃである。攻撃者にしてみれば、誰でも手に入れられるCMSであれば、
a-blog cmsの公式サイトを拝見すると、MySQLを利用しているようで、
ファイルの暗号化はなされていようとも、DBの中身の仕様は丸見えだ。
前提条件として「知っている」「知らない」の差はあれど、攻撃に関して「ラク」というのは
どう考えても楽観的に過ぎる考えだ。
どうも「SSLで確保される安全の領域」について、かなり認識が甘いようだ。
SSLはあくまで、TCP/IPネットワークにおいて通信経路を暗号化するための技術だ。
通信する際に、通信先のサーバーが正しく認証されているかどうか?に必要なのはSSL証明書。
で、ここに書いたとおり、SSLはあくまでサーバーと利用者の通信においての暗号化だ。
この記事に書かれていることは「メールフォームについて」のことのようだが、
サーバーに到達したあとのメールについては安全性をかんがえていますか?
メールは全く暗号化されず平文で送信されるとても脆弱な通信手段だ。
いくらSSLで通信を暗号化しようとも、問い合わせフォームの送信がメールだったとすると…
とこの記事ではかかれていますが、そもそもHTTPやHTTPSの通信を傍受するより遥かに
メールを傍受したほうがラクとも考えられるはず。
CMSの機能に甘んじて、こういったベーシックな問題に考えが及んでいないとすると、
とおもう。
記事に対するつっこみではないですが、
正しくは「TLS」でっせ。
この記事は増田アドベントカレンダー23日目の記事です。
時間がないのと厳密に言うと漏らしたわけではないのでやっぱやめた。
いろいろ申し訳ない。
[開催日] 12月25日
[場所] IRCサーバ( irc.anonops.com ) ch: #MerryChristMasda
・各人適当な増田ネームをつける(はてなidが分かるような名前はダメ)
・25日の20時までに各人は持ち物をもって会場へ入場
・なお、会場は既に入場可能なので自由に出入りOK
・25日の夜にみんなで祝おう!
・進行は適当。
・増田への記事投下は25日の20時~24時。投下方法はチャットで話しあうとかして決める。
・会場はIRCクライアントを使ってSSL接続推奨だけど、webchatからの参加も大歓迎だよ!(anonops webchat) ※webchat経由の場合は接続後に「/JOIN #MerryChristMasda hatena」と書き込むと入室できます。
・匿名ちゃっと環境としてanonopsを選び、ch登録までは増田がすませています。よって、anonopsのルールにあわない書き込みや接続はNGです。
(追記)
hisawooo スタープラチナみたいになる人いそう
スターフェラチナ - Google 検索 : https://www.google.co.jp/search?hl=ja&q=%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%A9%E3%83%81%E3%83%8A&lr=lang_ja&gws_rd=ssl#safe=off&hl=ja&q=%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%95%E3%82%A7%E3%83%A9%E3%83%81%E3%83%8A
約2,100件
サイト名 | ジャンル | 作者登録 | ルビ | 挿絵 | アクセス解析 | EPUB | モバイル | SSL | 料金 | 開始 | |
---|---|---|---|---|---|---|---|---|---|---|---|
作家でごはん! | 自由 | 不要 | - | - | - | - | - | - | - | 無料 | 1998年 |
ノベリスト.jp | 自由 | 必要 | - | ○ | ○ | - | - | - | - | 無料 | 2009年 |
星空文庫 | 自由 | 必要 | ○ | ○ | ○ | ○ | ○ | - | ○ | 無料 | 2010年 |
ふみふみ | 自由 | 必要 | ○ | ○ | - | ○ | - | - | - | 無料 | 2008年 |
dNoVeLs | 自由 | 必要 | - | ○ | - | - | ○ | ○ | - | 一部有料 | 2008年 |
FC2小説 | 自由 | 必要 | - | - | - | - | - | ○ | - | 無料 | 2008年 |
のべぷろ! | ライトノベル | 必要 | - | ○ | - | - | - | ○ | ○ | 一部有料 | 2009年 |
小説家になろう | ライトノベル | 必要 | ○ | ○ | ○ | - | ○ | ○ | - | 無料 | 2004年 |
アットノベルス | ライトノベル | 必要 | ○ | ○ | - | - | - | ○ | - | 無料 | 2009年 |
ライトノベル作法研究所 | ライトノベル | 不要 | - | - | - | - | - | - | - | 無料 | 2004年 |
ラノベジェネレーション | ライトノベル | 必要 | - | ○ | - | - | - | - | - | 無料 | 2010年 |
Arcadia | ライトノベル | 不要 | - | - | - | - | - | - | - | 無料 | 2000年 |
小説カキコ | ライトノベル 二次創作 | 不要 | - | - | - | - | - | ○ | - | 無料 | 2007年 |
SS投稿速報 | 二次創作 | 必要 | - | - | ○ | - | - | - | - | 無料 | 2014年 |
すぴばる小説部 | 二次創作 ドリーム小説 | 必要 | - | ○ | - | - | - | - | ○ | 無料 | 2011年 |
QBOOKS | 短編 | 必要 | - | - | - | - | - | ○ | - | 無料 | 1998年 |
jyunbun | 純文学 | 不要 | - | ○ | - | - | - | - | - | 無料 | 2010年 |
幻創文庫 | 官能小説 | 必要 | - | - | ○ | - | - | ○ | - | 無料 | 2004年 |
PiPi's World『投稿小説』 | 官能小説 | 不要 | - | - | - | - | - | ○ | - | 無料 | 2002年 |
ここブックマークしとけ
あとはまだ登録数少ないけどこれ入れとけ
例のAppleのSSL/TLSのバグの件、日本語情報がなかったので意訳しました。
Adam Langleyさんによって書かれた原文はこちら。要所要所に親切なリンクがついているので、ぜひ原文も見てみてください。
Apple's SSL/TLS bug (22 Feb 2014)
https://www.imperialviolet.org/2014/02/22/applebug.html
(Hi Adam Langley, Than you for your blog! We really appreciate you.)
-----
昨日、AppleはばかばかしいiOS向けのセキュリティアップデートを発行した。 それは詳しく明かされていないが、SSL/TSLについてとんでもなく恐ろしい間違いを示すものだった。 その答えは既にハッカーニュースのトップにタレこまれている(https://news.ycombinator.com/item?id=7281378)し、アップルが隠したい秘密はもうバレてしまっていると思う。 そして現在、俺たちはその誤った情報を正すステージに来ているんだ。 ほらここに、Appleのbugがあるんだ。:
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { OSStatus err; ... if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; ... fail: SSLFreeBuffer(&signedHashes); SSLFreeBuffer(&hashCtx); return err; }(Quoted from Apple's published source code.)
(訳者注:(Quoted from Apple's published source code)→sslKeyExchange.c) 2行のgotoがあるだろ。 2行目のgotoは、見て分かる通り常に発動する。 変数[err]にはエラーを示す値が入らず、正常を示す値のままfailに飛ぶってことだ。 それって成功したのと同じなんだよね! この署名検証処理は(訳者注:SSL/TLSハンドシェイクのやりとりのうちの一つである)ServerKeyExchangeメッセージの署名を検証するものだ。 このServerKeyExchangeでは、"the ephemeral key"(通信のための一時的な鍵)を交換するためのDHE や ECDHE という暗号スイートが使われる。 そのサーバーは言うんだ。 「ここに"the ephemeral key"と署名があるよ、ほら、これが証明書だ。君はこれが僕からのものだってわかってくれるよね!」 今、もし"the ephemeral key"と証明書の関係が破たんしているならば、すべては無意味なんだ。 これってつまり、正規の証明書チェーンをクライアントに送信したけど、ハンドシェイクへの署名には正しくない間違った(つまり適当にその辺で作った)鍵を使ったり、そもそもハンドシェイクに署名しなかったりってことができるってことなんだよ! そこには、今君が通信しているサーバーが、サーバー証明書に含まれる公開鍵の秘密鍵を持っているってことの証明が、何もないんだ。 これはSecureTransport(というライブラリ)に入っていて、以下に影響する。 ・iOS 7.0.6より前(俺は7.0.4で確認した) ・OS X 10.9.2より前(10.9.1で確認した) (訳者注:つまりiOS 7.0.6、OS X 10.9.2で解決した) これはSecureTransportを使っているすべてに影響するけど、ChromeとFirefoxはそうじゃない。 ChromeとFirefoxはSSL/TLSのためにNSSを使っている。 でも、それはあんまり君のマシンがSecureTransportを使っていないってことを意味しないよ。(ソフトって更新されるしね) 超特急でテストサイトを作ってみたよ。https://www.imperialviolet.org:1266 ポート番号に気を付けてね。(テストサイトはCVE番号になってるよ) 443は通常通りに動いているからね。 ポート1266のサーバーと443のサーバーは同じ証明書を送っているけど、完全に異なるキーで署名しているんだ。 君がもしポート1266のHTTPSサイトにアクセスできたんだったら、君のマシンはこのイケてるバグを抱えてるってことだね。:) それってつまり、証明書チェーンは正しいってことで、そしてハンドシェイクと証明書チェーンの関係は壊れたってことで、もう俺はどんな証明書も信じないよ。 またこれは、DHE または ECDHE 暗号スイートを使っているサイトに影響を及ぼすだけじゃないんだ。 攻撃者は、この暗号スイートを使うサーバーを自分で建てるようになるだろう。 また、これはTLS 1.2には影響しない。このバグを含まないTLS 1.2の別の関数があったから。 でも攻撃者は使うプロトコルをある程度選ぶことができるから、安心できないよ。 (訳者注:サーバー側がTLS1.2を使えないことにしていたら、それ以外の例えばSSL3.0とかTLS1.0とか1.1で通信が始まっちゃうから。) でもでも、クライアント側でTLS1.2だけを使えるようにしておけば、それは今回の問題の回避策になる。。 同じく、クライアント側でRSA暗号スイートだけを許可するということも、ServerKeyExchangeが発生しなくなるので今回の問題の回避策になる。 (2つのうち、1つ目のほうがだいぶ好ましい。) 俺のテストサイトでは、iOS 7.0.6 と OS X 10.9.2で問題は解決していた。 (更新:このバグはOS X 10.9 のときに入ったように見えたけど、iOS6にもっあったぽい。iOS 6.1.6は昨日リリースされたよ。) こんなような微妙なバグって、悪夢だ。 俺はこれは単なるミスだと思うし、なんかもうほんと最悪って思う。 ここに、今回の問題を明らかにするコードがある。:
extern int f(); int g() { int ret = 1; goto out; ret = f(); out: return ret; }
もし俺が"-Wall "を付けてコンパイルしたとしても、XcodeのGCC 4.8.2 や Clang 3.3は死んでるコード(the dead code)について警告をしないんだ。 本当にビックリだよ!!! ここで警告が出ていたらこの問題は止められたのに。でもたぶん、現実には死んでるコードが多すぎて無視することにしてるんだろうね。 (ピーター・ネルソンが教えてくれたけど、Clangはこれを警告するための"-Wunreachable-code"を持ってる。でもこれ、なんと"-Wall "には含まれてない!) if文に{}をつけないことを許すコーディングスタイルはこの問題を誘発したかもしれない。 でも、人は{}を付けたとしても間違ったプログラムを書くことがあるから、これは俺はあんまり関係ないように思う。 テストケースはこれを見つけることができたはずだけど、今回のはいろいろ条件が複雑なやつだったから難しかったと思う。 TLSのめちゃめちゃ多くのオプションを試さなきゃいけなかったからね。しかも正常系じゃないやつも。 俺、TLSLiteでちゃんとテストしてるか思い出せないもん。(月曜日怖いかも) コードレビューはこの種類のバグについて効果的でありえる。 ただし単なる審査じゃなく、それぞれの変更に対してしっかりとレビューすることだ。 Appleのコードレビューカルチャーがどんなもんか知らないけど、もし俺が同じようなことをやっちゃったとしたら、同僚のWan-Teh や Ryan Sleevi がばっちり見つけてくれたと、固く信じてる。 でも、誰もがそんなにいい仲間を持てるわけじゃないよね。 最後に。昨日、Appleが証明書のホスト名をちゃんとチェックしていなかったことについて多くの議論があったんだけど、 それは OS X のコマンドラインでcurlを使うと、IPじゃない証明書でもIPでHTTPSにつながっちゃうってだけだったよ。変だけど。 Safariはこの問題には関係なかったよ。
ちなみに、別件でOpenSSL使ったセキュリティー(C)をやらせたら、丸投げ外注だと数ヶ月たっても上がってこなかったけど、
仕方がないから、ノウハウ開示して指導しながらやったら7日で出来た。(テスト別)
実作業で言えばSIerがちゃんとしてればそんなもの。(実データ)
10年前かなぁ。おおざっぱに。
行って来い(復号可能)で、公開鍵使って10年前でそんなもの。OpenSSLを銀行じゃ使えないだろうがマシな商用SSLぐらいいくらでもあっただろう。
公開鍵使ってれば、外注じゃどうにもならん。アドミンでも抜けない。
仕方がないという前提でいいけど、10年以上技術水準が遅れちゃってるという事実は関係者一同が認識するべき事態だと思う。暗号化だけで言えば20年近く概念が遅れてる。
情報漏洩自体は不正利用自体は金で片がつく事ではあるけど、経営幹部のITに対する知識が20年遅れているというのは、日本全体としてはピンチだろう?
俺達が何を言っているかわかってほしい。
この日記見つかるだろうか。
富山県のとある”にいかわ若者サポートステーション”(以下サポステ)のサイトがお察しなのが改善されないから適当に書く。特に次の4点は重症と考える。
1.厚生労働省認可事業であるのに、厚生労働省の当該ページへのリンクがない
自らのサイトより信頼性の高いサイトからリンクされているのであるなら、それを利用して自らのサイトの信用性を上げるのは重要と考える。EV-SSLなど第三者認証を利用できないのであれば、コストのかからない方法により信頼性を高めるのが重要である。以下に厚生労働省の当該ページの1例を示す。
http://www.mhlw.go.jp/bunya/nouryoku/ys-station/
使われる技術(WordPress)が優秀でもインターフェイス設計(サイトデザイン)が伴わないと使う意味は薄いと考える。
デザインの流行は常に移り変わるため常に研究が欠かせない。容易に研究できコストのかからない方法として、大手企業のサイトは参考になる。
プライバシーポリシーや利用規約など運営の基本となるページのアドレスが、デフォルト設定のまま2バイト文字列がエンコードされたアドレスで作成されている。
個人情報管理が最重要であるにもかかわらず、これら重要情報が明記されたページがこれでは信用性が下がると考える。検索エンジンや各種通知方法により直接リンクを貼り付けるさいにも支障をきたすため、英数字による固有アドレスへの変更が重要である。
Googleストリートビューのほうが遥かに分かりやすい、と書きたいがストリートビュー未対応エリアであった。
アクセス情報で重要なのは、近隣の重要な点となる「主要道路の交差点」や「最寄り駅・バス停」からの道のりであると考える。映像開始がすでにビルの前から始まるので、ここまで来れる人であれば動画を見なくても辿り着ける。また、基本的に画面がズームのままで見にくく、周囲の情報が見えないので案内になっていない。
そのほか、
・「キカクル」ってなに、説明が何もない。
スケジュールやお知らせに見かける「キカクル」の説明がない。
・職員紹介の動画でシーン切り替えが雑。
フェードイン・アウトがなく唐突に黒画面になる。黒画面に意味があるのか分からない。
無断使用を禁じるのであればPDF変換し文書セキュリティをかければよい。閲覧者としてもPPTよりもPDFのほうが閲覧環境が普及していると考える。
・PDFのみは基本手抜きに思える
IR情報など情報の改変・表示のずれが重要な問題となるならば分かるのだが、そうでないならば閲覧者としては普通のページとして構築して欲しい。PDFは改変されにくく作成者の意図通りに表示できるのが利点であるが、これらは作成者の都合である。
・終了したプログラムと継続してるプログラムが区別無くリストされてる
すでに終了した「集中訓練プログラム」と、現在も継続されている「スポーツプログラム」が同一のカテゴリに表示され区別されていない。
この日記自体個人的なことを書いているが、それでもなお個人的であるがページトップにある電話のアイコン画像がうさんくさいサイトに仕立て上げてるように見える。
はじめに僕はプログラムが苦手です。
ほんとに苦手です。
誰かがやってくれるんであれば絶対自分でプログラムしようなんて思いません。
寝る時もあーやってこうやったらこうなるとか考えてしまって睡眠不足になるし
9年くらい前のことです。
仕事でプログラムを使う必要があったので仕方なくparlの本を買ってきてシコシコやってました。
おなじみの「 hello world 」とかをモニターに表示させたりしました。
ものすごく簡単に理解してもらうためにこういう感じ書いてるんでしょうけど
ぶっちゃけ、本やネットの通り学習していくと大半の人が前半で飽きるか挫折します。
掲示板作ってどうするの?
自分に興味のないことをやるのって絶対続かないし覚えないんですよね!
僕もperlを学習したあとJavaを覚えようかなと本を買ってきて一通りやってみたんですけど
書かれてあるとおりに電卓とか作っても全く興味ないし作りたくもなかったので
全然頭に入ってきませんでした。
多分、すごい勢いでいろんなことを覚えていくと思います!(男ならw)
最近、そんなことをエロいWEBサービスを作りながら考えていました。
もうほんとに楽しくて、夢中になって自家発電・・いえ、プログラムしていました。
「はじめてのエロサイト」
「3日でできるエロ」
「できるエロサイト」
こんな感じのタイトルの本があったら僕だったら間違いなく買いますw
そんなわけでこれからプログラムを始めようと思っている人はエロい物をプログラムで作ってみてはいかがでしょうか?
そして、僕が今回作ったエロサービス(エロ動画検索兼ランキングサイト)
http://adultmovie-clip.com/ を作るのに必要だった知識について書いてみますので参考にしてみて下さい。
【今回作った物はどんなWEBサービスか?】
お気に入りの動画はログインなしでブックマークできるようにする。
人気ブログランキングのように外部サイトを登録できるようにし逆アクセスランキング機能をつける。
【必要な知識】
■html
http://www.tohoho-web.com/wwwbeg.htm
今回はhtml5でやってみた。
http://webdesignrecipes.com/semantic-html5-with-outline/
http://higashizm.sakura.ne.jp/jquery_first/
http://webdesignrecipes.com/jquery-beginners-guide-for-web-design/
http://helog.jp/javascript-2/jquery-javascript-2/1406/
■php
phpの基礎からできるからおすすめでかつデータベースの勉強もできる
エロデータの作成はスクレイピング(エロ動画データの収集)により行う。
例えば
該当ページをhtmlSQLで取得する。
http://tenderfeel.xsrv.jp/php/628/
http://plog.pya.jp/program/php/lesson11/sample01.html
ランキング部に利用、APIがあるのでリファラーでサイトのアクセス数をカウント
http://kota.oue.me/php%E3%81%A7google-analytics-api%E3%82%92%E3%81%84%E3%81%98%E3%82%8B%E3%80%82/
https://developers.google.com/analytics/resources/articles/gdataCommonQueries?hl=ja
■負荷対策
http://www.doyouphp.jp/tips/tips_apc.shtml
mod_evasive
DOS対策
http://www.makizou.com/archives/1341
mod_expires
http://www.ahref.org/tech/server/apacche/389.html
http://thinkit.co.jp/free/article/0707/2/6/
■サーバー関係
VPSを借りてこのサイトの通りやればWEBサーバーが構築できる。
できればメモリは1Gほしい。
無修正じゃなければKAGOYAのVPSでいいんではないでしょうか。
外部に公開しないのであればローカルでシコシコして下さい。
SSH・・・クライアント(Windows)からLinuxサーバーをリモート操作する
apache・・・WEBサーバー ※チューニング関係はググりまくって下さい。
mysql・・・データベース 全文検索を利用する場合、一旦mysqlは削除してsennaをインストール。インストールする順序に気をつける http://anond.hatelabo.jp/20110804021353
chkrootkit・・・rootkit検知ツール導入
■全文検索
経験上、サーバー代にもならないと思うので今のところ掲載しません。
以上です。
3月くらいから心身ともに疲れきっていたのでリフレッシュする意味で作ってみました。
エロサービスは以前にも何度か作っていてその時は非常に楽しくてわくわくしながらプログラムしていたので
それを思い出して、じゃあ作ってみようという感じです。
いろんな意味でw
学生が就職活動で、WEB系の会社で面接した時なんかにプログラムでどんなの作ったことある?と聞かれて
とか言っちゃうと「こいつできる」と思われるかもしれませんので(あくまで僕がそう思うだけですw)
これからプログラムをやろうと思ってる人はエロサービス作りで覚えてみて下さいw
きっとあっという間にできるようになりますw
さて最後になりますがこんなの作ってみたんでよかったら利用してみて下さい。
なんつうめんどくさい。。。
1.当然のことだが、最初に インターネットインフォメーションサービスと証明機関(WEB発行オプションも)の役割を追加
2.証明書の要求ファイルを作成(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)
3.自己署名入り証明書を作成(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)
4.サイトのDefault Siteへhttpsをバインド(IISマネージャのツリーのサイト名から Default Web Site 選択。右メニューのバインドでhttpsを追加。SSL証明書に自己署名した証明書を指定)
5.https://localhost/certSrv/ へアクセス。証明書を「詳細」要求する。ここで、要求ファイルの中身を貼り付ける。
7.https://localhost/certSrv/ へアクセス。発行された証明書をダウンロード。
8.「証明書の要求の完了」で、取り込み(IISマネージャを開いて、ツリーのサーバ名のところをクリック。右ペインのIISのところのサーバ証明書をダブルクリック。右の「操作」メニュー参照)