rabbit51

it's since Nov.30 2005
May.29 2014, transferred from broach

iPhone構成ファイルの暗号化スクリプト

2018-02-27 15:00:00 | iPhone
iPhone構成ファイルユーティリティのシミュレートで構成ファイルをテンプレートから生成したが、構成ファイル内に設定されたパスワードがある事から、デバイス毎に暗号化する事が求められる。
構成ファイルを暗号化するためには、「PayloadContnent」内の「array」データを取り出し暗号化する事。暗号化したデータを「EncryptedPayloadContent」として置き換える必要がある。エディターなどで編集することも可能であるが、一連の作業をスクリプトで自動化してみた。

構成ファイルから暗号化対象部分を取り出すのは、「iPhone構成ファイルユーティリティのシミュレート」で下記の処理で実現できることを示した。

Macでは、
/usr/bin/xmllint --xpath "/plist/dict/array" CertFile.mobileconfig > CertFile-CryptBody.mobileconfig
で、暗号化対象部分をファイル化できる。
構成ファイルの「Description」に2バイトコード(UTF-8)」の記述があると、抽出されたファイルでは、「松」が「松」などxml表記に変換される。ファイルとしては問題ないのだが、表示上「松」の文字が何であるか可読性が悪い。
また、構成ファイルから「暗号化対象」部分以外を取り出すのに「diff」を使用すると、暗号化対象部分にあるこれらの「2バイトコード」行が不一致行となってしまう。「暗号化対象」部分の抽出を行なっているのは、「xpath」なので、「xpath」を調べていると、OS Xには、「/usr/bin/xpath」があるらしい。直接実施してファイル化してみる。

/usr/bin/xpath CertFile.mobileconfig "/plist/dict/array" > CertFile-CryptBody.mobileconfig

「2バイトコード」の変換が行われていない。「xpath」を直接使うこととした。
構成ファイルを暗号化するために必要な一連のコマンドをまとめてみると

「WiFi_11nagb.mobileconfig」構成ファイルを対象とした暗号化プロセス
(1)暗号化対象部分の抽出
「/usr/bin/xpath WiFi_11nagb.mobileconfig "/plist/dict/array" > WiFi_11nagb-EncryptBody.txt」
(2)暗号化対象以外の抽出
「/usr/bin/diff -w --new-line-format='%L' --unchanged-line-format='' WiFi_11nagb.mobileconfig WiFi_11nagb-EncryptBody.txt > WiFi_11nagb-BasicBody.txt」
(3)暗号化対象部分の暗号化とBASE64化
「/usr/bin/openssl smime -encrypt -in WiFi_11nagb-EncryptBody.txt -outform der -CAfile CApub.pem device-cert.pem | /usr/bin/openssl base64 -out WiFi_11nagb-crypted.b64」
(4)「WiFi_11nagb-BasicBody.txt」内の「<key>PayloadContent</key>」を「<key>EncryptedPayloadContent</key>¥n<data>WiFi_11nagb-crypted.b64の内容</data>¥n」で置き換える
(5)置き換えられたテキスト(4)を「WiFi_11nagb-Encrypted.txt」ファイルとして書き出す
(6)署名する
「/usr/bin/openssl smime -sign -in WiFi_11nagb-Encrypted.txt -signer CApub.pem -inkey CAkey.pem -outform der -out WiFi_11nagb-Encrypted-Signed.mobileconfig -nodetach」

OS X標準で使用できる「perl」で作成した


実行


コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

iPhone iOS11アップデートの「あとで」選択

2018-01-25 13:00:00 | iPhone
今まで見逃していたのか、新しい機能なのか?
アップデートの「あとで」選択が増えているような気がする。
「あとで」選択すると、夜間にアップデートするには、パスワードの事前入力が求められる。電源に接続が必須らしい。

設定が完了すると「自動インストール」のキャンセル選択枝が増える。

一周遅れのアップデートだったので、11.2.2のインストール後、11.2.5のアップデート通知が表示された。「今すぐインストール」を選択する

「今すぐインストール」では、自動インストールのキャンセル選択肢表示はない。

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

iPhone(iOS11)に自己署名ルート証明書を追加し信頼させる

2018-01-09 09:56:24 | iPhone
Synology DS-216JにWebStationパッケージを追加インストールし、インターネットからはLet'sEncryptのサーバ証明書でアクセスし、ローカルネットワーク内からは自己署名CA発行のサーバ証明書でSSL接続するよう構成した。
iPhoneをWiFi接続してDS-216JのDSMへ接続するためDS-216Jに設定した自己署名CAのルート証明書(公開鍵)をiPhoneにインストールした。

この状態でDS216Jにローカルネットワークから接続すると自己署名CAの発行したサーバ証明書が提示され、SSL接続されるはずである。接続して見ると

「接続はプライベートではありません」?意味が判らない。。。。
「詳細を表示」をタップする
どうもiPhoneは、「有効でない証明書」と判断しているようだ。。。。
「証明書を見る」をタップして証明書を確認する

サーバ証明書が「信頼されていません」とのこと。。。。
「このWebサイトを閲覧」をタップする

サーバ証明書に不具合があるわけでは無いようだ。

どうしたら信頼させられるのだろうか?
今まで気がつかなかったのか、新たに機能追加されたのか、「設定」「一般」「情報」の一番下に「証明書信頼設定」なるエントリーが。。。。

追加した自己署名のルート証明書を信頼するようスイッチをオンにする
「設定」「一般」「プロファイル」で追加した自己署名ルート証明書に何かマークがつくのか確認してみたが

特に変化はない。

「接続はプライベートではありません」が表示されることは無くなった。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

iPhone用「ぷらら」メール構成ファイル

2017-11-27 18:44:27 | iPhone
「iPhone構成ユーティリティ」のシミュレートでTemplateを提示している。基本部とmailペイロード部の「REPLACE」を含むコメントを設定値で置き換え、メール設定用構成ファイルを完成させる。

「ぷらら」メール用の構成ファイルにしてみた。


「someone@server.plala.or.jp」を発行されたメールアドレスに変更する
「7609.............BFE1B」のUUID部を新しいUUIDに変更する
「ipcu.sim.mail.plala」部を必要があれば、変更する。UUIDを付加しているので変更しなくても良い
「AF855...........53C2」のUUID部を新しいUUIDに変更する
「account_id」を基本メールや追加メールに従い、設定する
「@server.plala.or.jp」をメールボックス名として設定(変更可)
「passwd」を基本メールや追加メールアカウントに従い、設定する

生パスワードが書かれたファイルになるので特定のiPhone用に暗号化するのがベスト。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

iPhoneで「ぷらら」メール・アクセス・トラブル解消か

2017-11-18 18:32:21 | iPhone
iPhoneで「ぷらら」のメールソフト設定(iPod touch/iPhone)でアクセスすることが出来る。テキストメールの送信では、問題無く送信できていた。
ある時、添付ファイルメールを送信すると何度も失敗して送信できなかった(たまに送信できる時がある)。多くの場合、比較的大きめのサイズの写真(jpg)やpdfで送信できない事が多かった。

Submissionポート587でSSLオフにすると何の問題も無く送信ができていた。
Submissionポートでメール送信を行う時は、認証が必要になる。認証データは、plain text指定なので、通信路のTLS化は必要と思う。ただ、SSLをオンにすると送信できたり、送信できなかったりで「ぷらら」に問い合わせるにも発生条件を特定する必要があった。
opensslのクライアント機能を使い、SSL接続でsmtp送信してみた。結果、data送信中に応答が無くなる事まで解った。発生したり、発生しなかったりするのは、サーバのSSL機能が間に合わないかロードバランサー背後のサーバに悪さをするサーバが居るかだろう。どちらの可能性があるか探るために、data早出速度を制御した送信プログラムを作りテストしたところ、javaの送信速度が遅いのか、現象が発生しなくなってしまった。去年の3月(2016年3月)頃だった。

つい最近ぷららから1通のメールが届いた。1日前の通知とはどうかと思うが。

停止する事なく、応答だけがかなり遅い状態だった。それでも最低1週間前には通知するのが一般的では無いか?

設備交換のようなので、送信サーバ「secure.plala.or.jp」をテストしてみた。
(1)ポート25

(2)ポート25のstartTLS

(3)サブミッションポート587

(4)サブミッションポート587のstartTLS

(5)サブミッションポート465のTLS


「ehlo」で「size=20,971,520」なので、送信ファイルサイズに制限があるようだ。概ねバイナリファイル10Mbytesまで。

早速、サブミッションポート587でSSLオフにしてあったiPhoneの設定をサブミッションポート587のSSLオンにして大きなサイズのファイルを添付して送信してみた。
今の所、送信失敗は無い。
Mac/MacbookのApple mailでもサブミッションポート587のstartTLSでアクセスが可能だった(2017年11月18日時点)。受信側もPOP3でなくIMAPのSSL設定が可能でぷららガイド(2017年11月18日時点)に従わないのが正解であろう。
MacbookのApple Mail設定を送受信共にTLS設定にした

特に問題なくアクセス出来ている。

早速、全てのツールの送信設定をポート587のstartTLS設定に戻そう。

(6)imapsであるポート993 のSSLも確認してみる

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする