JDBな人生  専門的なことから日常的なことまで~ まぁ自由きままに書いていきます。
2017年11月 / 10月<< 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>12月

アクセスランキング

[ジャンルランキング]
コンピュータ
261位
アクセスランキングを見る>>

[サブジャンルランキング]
プログラミング
37位
アクセスランキングを見る>>

クライアント認証の有効範囲

久々に技術系の記事を書こうと思います。
先日、管理しているWEBサイトの一つに、管理者用のコンテンツへのアクセス制限を目的として、クライアント認証を導入しました。

通常、phpMyAdminのような管理画面は、外部に公開する必要はありません。その場合、ローカルネットワーク内からのみアクセスを許可のうえ、VPNで接続するという形態をとるのが一般的かと思いますが、VPNが未設定のときにはそこから始める必要があります。
今回がその「未設定の状況」で、さすがにVPNの設定から行うのは手間がかかりすぎるということで、クライアント認証の導入という形で済ませることになったわけです。
あえてOSIモデルでいえば、ネットワーク層での制限ではなく、セッション層とアプリケーション層での制限という形ですね。

CAの構築・クライアント証明書の発行・署名等は今回の記事の趣旨から外れるので省略します。

さて、通常の設定だと以下のようになるはずです。

server {
(中略)
        ssl on;
        ssl_certificate (CERT)
        ssl_certificate_key (KEY)

        ssl_verify_client    on;
        ssl_client_certificate (CERT)
        ssl_verify_depth    1;
}


しかし、この記述のように、サーバ証明書が既に導入済みで、特定のディレクトリに関してだけクライアント認証「も」導入したい、というケースがあります。そこで「もし一部のディレクトリだけクライアント認証を設定できたら…」と考えると、次のような記述になるはずです。

server {
(中略)
        ssl on;
        ssl_certificate (CERT)
        ssl_certificate_key (KEY)

        location /(LOCATION) {
            ssl_verify_client    on;
            ssl_client_certificate (CERT)
            ssl_verify_depth    1;
        }
}


まあ書き方からお察しの通り、この設定では動きません。(お恥ずかしながら試してしまいました)
冷静に考えればすぐわかることですが、この記事では改めて確認をしてみようと思います。大きく分けて3点。

① そもそもTLSはOSIモデルではトランスポート層に位置するプロトコルで、WEBでの利用であれば、HTTPの下位に入ります。
HTTP等のプレゼンテーション層・アプリケーション層の通信を下位レベルで暗号化することが目的なので当然ですね。

② TLSのセッション確立は、
1. サーバ証明書送信 + 必要に応じてクライアント証明書を要求
2. 要求があればクライアント証明書送信
3. ごにょごにょ(証明書検証、プリマスタシークレット送信・マスタシークレットの生成、MACの交換・検証…)
4. 暗号化鍵生成
5. アプリケーション層の通信を開始
という手順で行われます。

③ locationディレクティブは、HTTPヘッダのGETやPOST等メソッド名の後に続くパスをもとに振り分けます。すなわち、アプリケーション層の情報を元にしています。

②を見ると、「クライアント証明書の利用の有無」のあとに「アプリケーション層の通信」が行われるわけですから、③のlocationディレクティブ判定=アプリケーション層の通信が行われるころには、すでにTLSのセッションは確立(②は終わっている)してしまっています。「クライアント証明書の使用の有無」も含めて、すでに話がまとまってしまっているため、後から蒸し返すことはできないというわけです。

HTTPの通信はTLSのセッション確立を前提とするため、locationディレクティブ(HTTPヘッダの一部)はTLSのセッション確立後に処理される。クライアント証明書の使用の有無はTLSのセッション確立時にしか決定できず、後からlocationディレクティブの内容によって切り替えることはできない。ということですね。

結局この問題をどう解決したかというと、「サーバ証明書のみ利用する仮想サーバ」「サーバ証明書とクライアント証明書の両方を利用する仮想サーバ」の二つを起動して、ポート番号で振り分けるという形態にしました。
安全性の確保という点でも、管理者用のエリアをより確実に隔離することにつながるので、この方が良かったですね。

さて、見返してみると誰得にもほどがあるような記事になってしまいましたが、広告がうっとうしかったのでご容赦ください。(論理の飛躍?気にしない気にしない)
しばらく時間ができそうなので、技術系の記事・エッセイともに公開をしていこうと思います。

インフルエンザが流行ってきていますが、くれぐれも気を付けたいですね。ではでは。
スポンサーサイト
   WEBサイト/ページ    TB(0)    CM(0)    EDIT    ページ↑

スマートフォン向けWEBアプリケーションのフレームワークの開発

一か月ぶりの更新となってしまいました。

先々月から、主にスマートフォン向けのWEBベースのアプリケーションフレームワークの開発をしています。(といってもここ一か月はほとんど触っていませんが…)

基本的には、端末やブラウザの違いに影響されずに一定のUXを提供する、というのが目標です。

現在実装されている機能としては、以下のような感じです。まだまだ中途半端といえば中途半端な出来ではありますが、今後も少しずつ機能を追加して、外部向けに公開できるくらいまで完成度を上げたいと考えています。

(UI関連)
・リスト状のデータを表示するインターフェース(AndroidのListViewとAdapter/iOSのCollectionViewに相当)
・ユーザに対し簡単な情報を表示するインターフェース(AndroidのToastに相当)
・各画面の移動に関する機能(AndroidのActivity遷移/Intentに相当)
・ユーザによるカスタマイズ機能に関するインターフェース(iOSのTableViewに相当)
・項目の一覧選択を行うインターフェース(.NETのListBoxに相当)
・フェードのよる要素の表示/非表示の切り替え

(内部処理系)
・TouchEvent/ClickEventの処理を統一するインターフェース
・非同期通信に関する処理
・Cookie/WebStorage/Query/Hash等の操作に関する機能
…などこちらは主にこれまでこのブログに載せてきたコードの寄せ集めです。

開発コード等は特に決まっていない…のですが、とりあえず自分の使っているハンドルネームをくっつけて"JLT WebApp Framework"とでもしておきましょうか。

今後特に力を入れたい点は、UIの機能追加と改良、例外処理の改良、オフライン動作への対応といったところです。

(画面イメージ)
131006pc.png

131006and.png

131006ios6.png

131006ios7.png

またTips等記事を書いていきたいと思います。
   WEBサイト/ページ    TB(0)    CM(0)    EDIT    ページ↑

Twitterのスパム

最近、月に1回から2回、スパムが来ます。
特に、フォロワーがフィッシングサイトに引っ掛かり、ダイレクトメッセージが自動で送信される、というタイプのものが多いです。

例えば、こんな文章。

hey, someone is spreading nasty rumors about you [URL] ...

hey someone is making up cruel things that are about you [URL]

Best diet pill to lose 30 pounds in 1 month! [URL]

文章は、「誰かがあなたの悪口を書いている」「1か月で30ポンド(約13kg)痩せるダイエット」などの内容です。

そして、URLを見てみると、こんな感じ。念のためaguse経由での画像です。

アプリケーション連携のログイン画面に似せたもの。
121014.png

登録の確定画面(?)に似せたもの。
1210142.png


オリジナルも載せておきます。

アプリケーション認証
1210143.png

非常によくできている、ということがわかります。
もちろん、URLを見れば本家ではない、ということは容易に判断がつきます。

上の3つのスパムは、本人に通知を行ったところ返答があったので、完全に乗っ取るところまでは行かないようです。(良心的と言えば良心的?)

#しかし、このスパムを広げて何がしたいのでしょうか?

普段からパソコンを使用している人たちでも引っ掛かっているようです。
ダイレクトメッセージやリプライから移動したページでのユーザー名・パスワードの入力には要注意です。

Twitterに限らず、ログイン時にはできるだけ、URLの確認をするよう気を付けましょう。
酷似しているので、見た目だけでは判断できないと思います。
   WEBサイト/ページ    TB(0)    CM(0)    EDIT    ページ↑

【続】Gmailの「Re:」 “In-Reply-To”ヘッダ

前回の記事の続きです。
例の「スレッドビュー」の動作に関する話です。

色々と条件を変えながら実験をしてみたところ、

(件名がある場合)
・件名が「Re: 件名」の場合はスレッド単位でまとめる

(件名がない場合)
・件名が「Re:」で本文の引用が続く場合はスレッド単位でまとめる

と案外シンプルにまとまったと思ったのですが・・・・・
もう少し調べてみるとこれは全然間違いだということが判明しました。

Yahooメールとのやりとりではスレッドビューが動作し、(機種にもよると思いますが)携帯電話のとのやりとりでは動作しないようです。
さらに条件を変えて実験をした結果、もっと別の条件があるとわかりました。

送信したメールのMessage-IDヘッダと返信として受信したメールのIn-Reply-Toヘッダが一致する場合はスレッド単位でまとめる


Gmailから送信されるメールには「Message-ID」というヘッダが付加されます。
1204086.png

そしてそのメールに返信をする際に、メーラーによっては「In-Reply-To」というヘッダが付加されます。内容は先ほど送られてきたメールのMessage-IDと同じです。
12040862.png

ここまで書いてさらに説明を引用する必要もないと思いますが一応。

メールヘッダの一覧

In-Reply-To
返信時に、どのメールへの返信かを示す。通常はMessage-IDが指定される

つまり、この値が一致すれば返信として受信したのか単体のメールとして受信したのかが判別できるということです。

というわけで改めてまとめると、

(件名/本文の引用の有無に関係なく)
・送信したメールのMessage-IDヘッダと返信として受信したメールのIn-Reply-Toヘッダが一致する場合はスレッド単位でまとめる

(件名がある場合)
・件名が「Re: 件名」の場合はスレッド単位でまとめる

・どちらにも該当しない場合は返信として受信したメールでも別々で扱う



昨日のメールはこの中の3番目、そのため別々で扱われてしまいました。
120408_20120408185752.png


今回のケースでは「携帯電話からPCにメールを送るときは件名を書く」ということが一番簡単な解決策になると思います。
まあ、メールにはきちんと件名を書いたほうが良いよという話でした。

※この記事は仕様を調べたものではなくただひたすらメールの送受信を繰り返してわかったことを書いているので正確さは保証できません。間違い等がもしあれば指摘をよろしくお願いします。
   WEBサイト/ページ    TB(0)    CM(0)    EDIT    ページ↑

Gmailの「Re:」

Gmailというのは沢山の気の利く機能が搭載されたWEBメールですが、その一つにメールを自動でスレッドごとにまとめる機能「スレッドビュー」があります。昨日、その機能が何故か働かず、ちょっとおかしなことになりました。

通常このように(1204083.png)件名に「Re:」が含まれる場合は、スレッド単位でまとめてくれます。
1204082.png

しかし、場合によっては…
120408.png


こう綺麗に段々となっていると鬱陶しいどころか逆に面白い感じがしますが、何故この場合には一つのスレッドにまとめてくれないのか気になります。
おそらく原因は相手のメーラーだと思いますが・・・

というかふつうは「Re: Re: Re: Re: Re: Re:」なんてことにはならないのでしょうか?
件名がきちんと入っていればこうはならないのでしょうか?

明日もう少し調べてみます。

#どうせ段々になるならもう少し綺麗な形になってほしかったと思ったり
   WEBサイト/ページ    TB(0)    CM(1)    EDIT    ページ↑

プロフィール

JDB Luigi

Author:JDB Luigi
どこにでもいるようなありふれた人間・・・という訳でもなく、かと言って怪しい宗教を信仰する変人という訳でも無い。

基本的に掲載しているコード等は煮ていただいても焼いていただいても結構ですが、利用は自己責任にてお願いいします。
また、バグ・アドバイス等もしあればよろしくお願いします。

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。