なうろーでいんぐ
キーボード↑↓
でもいいぞ
旧サイト形式へ帰りたい人
公開鍵暗号のクライアントの意味合い
2014年04月21日11時25分
大抵その説明は、
クライアント側で生成した公開鍵を、
サーバー側に渡して通信する。
その一方で秘密鍵は一つしか無い。
だから混乱するのだが、これを見て納得行く。
http://yamanjo.net/knowledge/internet/internet_19.html
鍵の作成者は「受信者」本人に間違いない
という前提で成り立っている。
つまり、受信者がクライアント。

今まで使い方としては間違ってなかったけど、
概念とかの考え方がごちゃってたのでメモる。
秘密鍵で暗号化すると公開鍵でしか分からない。
公開鍵で暗号化すると秘密鍵でしか分からない。
これもまたその辺り混乱する原因だろうねぇ。

CAにはコードサイニング証明の際に、電話で
お世話になりました。

同日 20:05
ミニキャラとか頭の中で構成するのが楽に
なっちまってん。線引くと思考がぶれるけどな。
ファイル 1057-1.png
記事カテゴリ:プログラム関連
通信関連の確認
2014年04月20日10時11分
ASPでのHTTP通信処理を確認した。
ソケットプログラミングに比べてかなり楽。
まぁ、そりゃそうかと思いながら、GET、POST
してヘッダ取得からパラメータのパースやらで
一通り遊んだ後、SSL通信を見る。
ライブラリが色々ある中で、初見の単語を発見。
X.509、検索すると、公開鍵暗号とかの
デジタル証明書の標準仕様規格との事。
証明書の検証とかで幅広く使われている模様。
C#で使用例とかは結構見かけた。

一方、C++ソケットプログラミングを見に行くと
相変わらずのSTD混じりプログラミングに
懐かしさを覚えつつ、またやらななぁと感じる。
プロトコルとかホスト名処理とか、
なんだかんだでめんどくさ過ぎるのが億劫だが。

同日 16:37
LPICの読み進めでポートセキュリティ関連が
目に入ったので、ちょちょいと調査。
Nmapがハッカーにとっても超便利!などと
冗談は置いておいて、TCPやUDPにおける通信で
ACKやSYNの返答次第でサーバー情報を解析する
手法は、ある程度までネットワークの勉強を
すれば気が付く事でもある。
というか、実際はサービスを提供する以上、
そのポートは開きっぱなしであり、常に情報を
開示している状態なわけで、疎いならば
ザル警備になるのもしょうがないとも思う。
しかし、商用利用となると問屋が卸さない。
使用しているサービスのバージョンに応じた
セキュリティホールの穴埋めや、
iptablesによるフィルタリング、
定期ログ監視による不正検出と自動対処等
非常に幅広く知識が求められてしまう。
萎えるわ~、という正直なこころ。
まぁ、誰かがやらないとアカンのですがね。

同日 20:13
気がついたらなんかしてた。
ファイル 1056-1.png
記事カテゴリ:プログラム関連
久々にGPS関連
2014年04月18日07時36分
まず、国土交通省csvデータをDBへ移す。
http://nlftp.mlit.go.jp/cgi-bin/isj/dls/_choose_method.cgi

スマホの場合は個別にGPS取得プログラムがある。
AndroidならJava、iPhoneならObjective-C
統一機構としてwebブラウザ経由なら、
javascriptで渡してもいいが、
携帯には専用タグを利用するライブラリがある。
http://pear.php.net/package/Net_UserAgent_Mobile/
http://pear.php.net/package/Net_UserAgent_Mobile_GPS
内部的には抽象クラス定義の拡張になるので、
全部同じメソッドで実装していて非常に楽。
使い方が分からん人はググればすぐ出てくる。
後は取得したGPSのlatとlngをDB情報と比較して、
場所を特定して処理を返すだけナリ。
情報の錯綜していた昔に比べてずいぶんと
楽になったもんだ・・・。

同日 8:00
面白かった。
『東のエデン』が訴えてる日本の問題って
http://bipblog.com/archives/4750407.html
大方同意する。
最後の方で、ゲームとか物書きとかコンテンツで
人を動かせればみたいな発言があったが、
昔自分もそう考えてたけど実は根本的解決に
ならないと今は確信している。
直接的に影響ある行動しないと蚊帳の外だから。
大体、昨今の業界は金に腐心するばかりで
自由な発想で物を作れないし、
そういうの作りたいなら趣味が一番なのよね。
やはり、視野を広く現実を見ないとアカンよ。
記事カテゴリ:プログラム関連
PostFixのメーリングリスト処理
2014年04月14日15時19分
メールサーバーの動作は結構バラバラだけど、
EC系で触ってた機会が多い割に、
ログによるエラー原因追及とかしかやった記憶が
無いこのPostFixの概要を把握。
プログラミング言語との連携方法も分かった。

メーリングリストについてだが、
簡単に言えば、エイリアス使ってアドレスを
プログラムなりに飛ばし、プログラム側は
stdin(標準入力)でその内容を読解して
メールの返答を返す様にする。
読解はmimetypeやらが面倒なので他のライブラリ
使って、ヘッダ部分にあるfromにメールを返す。
ここを参考にすればいいと思うよ。
http://coelacanth.dip.jp/emptymail.php
後はその情報をDBなりに登録しておき、
送りたい時間にcrontab設定したりでもすれば
簡単メーリングリスト完成。

PostFixというかメールサーバー自体は何を
してくれるか、についてはある程度同じ機構で

Message User Agent
(メールソフトみたいな感じ)
Mail Retrieval Agent
(メールの受信担当)
Message Transfer Agent
(どこに送るかと一時的なデータ保持)
Main Delivery Agent
(実際に送る係)

が動く事でメールが処理できる。
プロトコルとしては基本的な話だが
POP(受信)
SMTP(送信)
IMAP(メールのコピーとか検索やら)
DNS(宛先の問い合わせ)
が必要。

過去、数千件のメーリングリスト動かした際に
どうしても時間がかかる問題ってのがあった。
簡単な話、専用サーバーじゃない上に、
プログラムでウェイトも無しに送出すると
スパムと間違えられて止められたのよねw
複数台のサーバーでバランシングするみたいな
贅沢な環境は限られてるので、ってか中小では
まず無かろうなので、一回の全送出に2時間は
かかってた懐かしい思い出。
記事カテゴリ:プログラム関連