自堕落な技術者の日記

基本は喰ってるか飲んでるかですが、よく趣味でカラオケ・PKI・署名・認証・プログラミング・情報セキュリティをやっています。旅好き。テレビ好きで芸能通

最近の証明書の話題(2): CloudFlare DNS 1.1.1.1サイトのIPv6証明書

今日も、証明書ハンターネタの第二弾ということで、、、

4月1日に公開になったAPNICとCloudFlareが提供する、レスポンスが速くて、プライバシーに配慮した噂の1.1.1.1というパブリックDNSサービスが利用できるようになりました。DNSサーバーは、通信が暗号化されていても、どのIPからどのIPにアクセスしたかという記録が残るので、それをターゲティング広告などに使ったりするそうです。このDNSサービスは、プライバシーに配慮してログの保存期間を1週間とし、広告などに使われないようにしているそうです。

こんな記事見ちゃうと通信全体で早くなるのかどうかはよくわからないですね。で、このサービスの公式紹介サイトhttps://1.1.1.1/なんですが、FQDNでなく、IPアドレスで発行しているわけです。何やらおもしろそうじゃないですか。早速、証明書をダウンロードしてみて、内容を見てみましょう。

$ openssl x509 -in ip1.1.1.1.cer -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 05:6c:de:b4:14:65:ff:27:07:16:c0:6e:91:16:2e:19 Signature Algorithm: <font color=“orange”>ecdsa-with-SHA256</font> Issuer: C=US, O=DigiCert Inc, CN=DigiCert ECC Secure Server CA Validity Not Before: Mar 30 00:00:00 2018 GMT Not After : Mar 25 12:00:00 2020 GMT Subject: C=US, ST=CA, L=San Francisco, O=Cloudflare, Inc., CN=*.cloudflare-dns.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b2:45:0b:31:ac:50:63:ce:21:e6:7c:34:23:1a: c5:c1:53:45:96:97:7a:31:87:bb:e0:ea:1d:95:f5: ff:25:04:ca:75:f0:f6:3f:b5:df:51:e9:5b:c9:3d: ad:b4:03:05:73:20:92:3e:74:be:8e:4b:1b:e2:68: 86:44:6e:62:bb ASN1 OID: prime256v1 NIST CURVE: P-256 X509v3 extensions: X509v3 Authority Key Identifier: keyid:A3:9D:E6:1F:F9:DA:39:4F:C0:6E:E8:91:CB:95:A5:DA:31:E2:0A:9F X509v3 Subject Key Identifier: DF:97:4D:E5:43:B3:B0:41:A7:42:F2:90:CF:89:7F:AE:12:57:84:E1 X509v3 Subject Alternative Name: DNS:*.cloudflare-dns.com, IP Address:1.1.1.1, IP Address:1.0.0.1, DNS:cloudflare-dns.com, IP Address:2606:4700:4700:0:0:0:0:1111, IP Address:2606:4700:4700:0:0:0:0:1001 X509v3 Key Usage: critical Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/ssca-ecc-g1.crl Full Name: URI:http://crl4.digicert.com/ssca-ecc-g1.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Policy: 2.23.140.1.2.2 Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/ DigiCertECCSecureServerCA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: ecdsa-with-SHA256 30:65:02:31:00:8e:8c:b2:d8:e8:21:d6:2d:7f:2a:1f:7e:a6: c3:1c:d4:e0:a1:95:02:2f:40:5e:80:92:88:d9:4b:cc:a5:89: aa:fa:9b:ca:b9:9e:a0:b7:a9:ed:21:1d:1d:1f:13:1c:0b:02: 30:2e:79:64:67:1d:7e:10:27:d9:68:a8:c8:6c:3e:4d:cd:07: 40:ac:d2:64:ad:b0:d0:cd:1b:af:c3:a4:26:30:ed:79:a3:a0: 6d:f2:d4:b4:bb:66:46:59:9a:a3:67:d9:0f
この証明書の特徴はこんなとこ:
  • DigiCertが発行している
  • 楕円曲線(ECC)の公開鍵証明書
  • 主体者別名(subjectAltName)にIPv4アドレスとIPv6アドレスが記載されている
いや〜〜〜、すごいですね。証明書ハンターなのでいろいろ証明書を探して見てますけど、IPv6アドレス向けのプライベートじゃない証明書を初めて見ましたよ。これは、早速コレクション対象ですよっ!!!

先日、データ通信協会のセミナーで総務省の方の講演を拝聴したんですが、 「iPhoneとかスマホのおかげでIPv6って本当に普及しちゃった。」と仰っていました。 ホント、その通りなんですねぇ。日本からGoogleへのアクセスは17%がIPv6なんだそうです。 Apple iOSでは、IPv4だと(わざと?)遅延させる仕組みが入るそうで、今後、IPv6への移行が加速されるだろうとの事でした。

実は、趣味で作ったjsrsasignというJavaScript実装の暗号/PKI関連ライブラリを公開しているんですが、よく考えてみたらIPv6対応してなかったんですよ。こりゃマズイなぁ、、、と。早速、対応させてみました。

最後のサンプルはいろんな証明書を簡単に作れるので、遊んでやってください。 そういう意味ではOpenSSLの証明書の表示は
IP Address:2606:4700:4700:0:0:0:0:1001
のような感じでRFC 5952で正規化されているわけではない、一意じゃない表記のやつなんですねぇ。正規化したらこうなりますよね。
IP Address:2606:4700:4700::1001
RFC 5952なんて知らなかったんですが、JPNICさんの「RFC5952-IPv6アドレスの推奨表記 IPv6アドレス表記の柔軟性が起こす問題とRFC5952の解説」を見て勉強させてもらいました。ありがたや。ありがたや。

てなわけで、今日もナイスな証明書をゲットだぜ。今日はこの辺で、、、

最近の証明書の話題(1) 韓国政府PKIのマズいワイルドカード証明書発行

どうも、証明書ハンターです。最近、個人的におもしろい証明書の話題がポンポン出てきたので、何回かに分けてご紹介したいと思います。

山賀さんのFacebookのフィードを見ていたら、 韓国政府PKIでまずい証明書を発行したというニュース(Google翻訳で読んでくださいw)を教えていただきまして、ハンターとしてはゲットしてコレクションに加えておきたいところ。

その問題というのは、韓国政府PKIが慶尚南道教育庁に不適切なワイルドカードSSLサーバー証明書を発行してしまったというもの。 慶尚南道は韓国の南東、釜山のすぐ北にあるのだそうです。

韓国のサイトは日本と同じでセカンドレベルを組織種別とする属性型ドメイン名を採用していて、政府系ドメインは「go.kr」のようになっていますが、以下のドメインに対してワイルドカードSSLサーバー証明書を発行してしまいました。

  • *.hs.kr - 高校
  • *.ms.kr - 中学校
  • *.es.kr - 小学校
  • *.kg.kr - 幼稚園
  • *.sc.kr - その他の学校
  • *.or.kr - 非営利団体
すると、この証明書と秘密鍵があれば、韓国の任意の学校のフィッシングサイトを作ったり、暗号通信の盗聴や改ざんができてしまう可能性があり、韓国政府認証基盤(GPKI)の信頼が揺らいでしまったとニュースでは指摘しています。一体、どんなドメイン確認処理(validation)をしてたんですかねぇ?

Google先生に聞いてみてもすぐはそのマズイ証明書が見つかりませんでしたが、Certificate Transparencyのログを見てみたら。ココにありました。(CTありがと〜〜〜〜、昔非難しててごめんよ〜〜〜(泣))

subjectAltNameを見てみると

X509v3 Subject Alternative Name: DNS:www.haeseong.kr DNS:haeseong.kr DNS:www.gandhischool.net DNS:gandhischool.net DNS:www.milgo.org DNS:milgo.org DNS:*.go.kr DNS:*.co.kr DNS:*.sc.kr DNS:*.or.kr DNS:*.kg.kr DNS:*.hs.kr DNS:*.ms.kr DNS:*.es.kr DNS:*.gne.go.kr DNS:support.gne.go.kr
一部の特定の高校まで入ってるのもどうかと思いますが、 バッチリワイルドカード入っちゃってますねぇ、、、って、あれれ??? 「*.go.kr」の政府向けドメインや「*.co.kr」企業向け のワイルドが入っちゃってるじゃないですか??? ニュースにある証明書のキャプチャと違うぞ!!! 学校サイトなんかど〜〜でもよくて、それより、 全韓国政府系ドメイン向けや、全韓国企業向けのワイルドの方が、 特大の問題で、盗聴なんかされたらマズイんじゃないですかねぇ。 そのあたりは報道が忖度したんですかねぇ、、、

ただ、このSSLサーバー証明書は、ルートが韓国政府のルートCAで、ChromeでもFirefoxでも信頼されたルートに入っていないから、韓国の人以外が被害に合うことは、ほとんど無いんじゃないかと思います。

で、この証明書がちゃんと失効されているか知りたかったんですが、CRLDPが

URI:ldap://ldap.epki.go.kr:389/cn=crl1p1dp14256,ou=CRL,ou=GPKI,o=Government of Korea,c=kr?certificateRevocationList;binary
LDAP URIになっていて、このLDAPサーバーがどうも匿名アクセスができず、普通にはCRLを取得できなそうにないんです。ChromeもFirefoxもIEもLDAP URIによる失効検証は(IEとADサーバーの組み合わせ以外は?)サポートしていないので、CRL失効検証はできず、OCSPもないようなので、どうやってブラウザで失効検証すりゃいんですかね?韓国のPKIに詳しいお友達がいる方は、教えていただけると嬉しいです。

というわけで、韓国GPKIのマズイ証明書発行のニュースを紹介し、私は無事、おもしろい証明書「ゲットだぜ!」

今日はこの辺で、、、あと二本ぐらい、近日中に書きたいと思ってます。

追記(2018.04.11)

他の韓国GPKI発行の証明書を見ていたら、HTTPからCRLを取れるようになっているようで、LDAP URIの情報から当該のCRLを取得することができました。で、中身を見てみたところ、このマズイ証明書も含め、現時点で一枚も失効させている証明書はありませんでしたので、一応ご報告。

追記(2018.04.14)

ちょっと探しものをしていたところ見つけた、韓国GPKIが発行している

Subject DN: CN=e-csinfo.*.go.kr
SAN DNS: e-csinfo.*.go.kr
このワイルドカード証明書もとても怪しい。 管理主体が全くわからず、全省庁の e-csinfo.*.go.kr サイトを保護しているって、 これ何だ???具体的なサイトは jbe.go.krsen.go.kr などがあるようで、共通管理はされているっぽいんだけど。

(小ネタ) Chrome 60で証明書を表示させるフラグ設定

Chrome 56からGoogleの「素人はすっこんでろ」UI/UXポリシーによりHTTPSで接続した際に使用しているSSLサーバー証明書の表示が鍵アイコンから簡単にできなくなってしまいました。証明書大好きっ子にはなんとも辛い仕打ちでした。開発ツールからは証明書が表示できるので、メニューを辿って操作するか、ショートカットキーを素振り100回していた方も多いのではと思います。

Windows: Ctrl + Shift + I or F12
Mac: ⌘ + Opt + I

今日は、やっとChrome 60からフラグ設定で証明書が簡単に表示できるようになったので、今日はその設定について紹介します。

何も設定していないと、HTTPSサイトを見ている際の、鍵アイコンをクリックして見られるメニューはこんな感じ。
before
そこで、アドレスバーで以下のように入力します。

chrome://flags/#show-cert-link
すると、このようなフラグ設定が表示されます。
flag
「有効にする」をクリックし、指示に従ってブラウザを再起動します。すると、HTTPSサイトを表示した場合このように
after
「証明書、有効」というリンクが表示されるようになり、クリックすると証明書が表示されるようになります。いや〜〜、よかった、よかった。
52

GmailアカウントでS/MIME 署名/暗号メールを使う(その1 iOS標準メーラー編)

とある匿名の紳士がご厚意で、JCANのS/MIME証明書をわたしのGmailのアドレスに発行してくださり、iOSの標準メーラーのGmailアカウントからS/MIME署名/暗号メールが送れるようになりました。 docomoアカウントのメールはS/MIME使えないので渡りに船でした。(匿名の淑女からいただいていたS/MIME証明書はとっくに期限切れになり困っていました。)

「ブログに書いて下さいよ〜〜〜」とその紳士に言われていたので、ちょっと書いてみたいと思います。

ここに書いてあるのは、JCAN証明書に限った話ではないので、iOS標準メーラーの任意のアカウント向けの証明書で使える話です。現時点で最新のiOS 10.3.2で試しました。

,泙困麓分のS/MIME証明書のインストール

発行された証明書と秘密鍵のファイルである「*.p12」や「*.pfx」を添付ファイルにしてiOS標準メーラーのアカウントに送り、添付ファイルを開きます。
IMG_2600m
表示されている「インストール」のリンクをクリックし、iOSのロック解除パスコードを入力し、続いて *.p12 または *.pfx ファイルのパスワードを入力すれば証明書がインストールされます。
IMG_2601m

⊆,GmailアカウントへのS/MIME証明書の設定

次に、iOSの標準メーラーからGmailのアカウントでS/MIME署名メールを送れるように、証明書(と鍵)の設定をします。「設定>メール>アカウント>Gmail>アカウント>詳細」の一番下の方にS/MIMEの設定があります。S/MIMEをオンにして「署名」を開き、
IMG_2602m
「署名」をオンにして証明書を選択します。JCANからの証明書は「BN-英語氏名」となっていると思います。
IMG_2603m
この時点では「デフォルトで暗号化」は「いいえ」のままがいいです。

iOS標準メーラーからS/MIME署名メールを送ってみる

iOS標準メーラーからGmailアカウントを選んで新規メールを送ってみましょう。
IMG_2604m
宛先が空欄の時には、錠前アイコンは「グレーで開いた」状態です。錠前が開いている状態は「相手に対して暗号化しませんよ」という意味です。また、グレーの錠前がある状態は「S/MIMEが利用可能」な状態にあるということです。次に、S/MIME署名メールを送りたい相手を選んでみましょう。
IMG_2606m
青い錠前が開いている状態は「メールの送信が可能で、相手にはS/MIME暗号化をしない」ということを意味しています。初期状態では相手の証明書をもらっていないので、暗号化できないのは当然です。ここで、無理やり「開いた青い錠前」をクリックしてみましょう。
IMG_2607m
相手の証明書を持っていないので、宛先が赤くなり「赤い錠前」のアイコンになり「暗号化できません」と表示されます。もう一度クリックして青に戻し、送信してみてください。

ちられてきた署名メールを受けてみる

iOSのメーラーから送られてきたメールをS/MIME対応のメーラー、例えばOutlookで見てみましょう。
zzz01m

ゥ僖愁灰鵐罅璽兇S/MIME署名メールから証明書を登録する

iPhoneから暗号メールまたは、署名暗号メールを送る場合には、iOSの標準メーラーのS/MIME関係の利用方法はいろいろイマイチな面が多いですが、署名メールに単純に返信する形では送れず、iPhoneでの相手証明書の事前登録が必要です。ここでは、その「相手の証明書」の登録方法を紹介します。

まず、送られてきた署名メールを開きます。
IMG_2606m
青い錠前をクリックしても、証明書が無いので赤くなるだけなので、もう一度タッチして青になるように戻します。
IMG_2607m
ちなみに、送られてきたメールが署名暗号メールだと、以下のようにバッジ(署名)と錠前(暗号化)の2つのアイコンつきます。
IMG_2609m
ちなみに、このメールをiPhoneの標準メーラーではなく、Gmailのウェブアプリで見てみると以下のようになっています。smime.p7mというファイルが添付されているだけで、暗号化されており、バイナリファイルを見ても内容はわからないでしょう。(そのうち、この中身のバイナリファイルの形式について述べることもあるかもしれません。) Googleにもメールの内容を知られることなく、安心ですね。
スクリーンショット 2017-06-09 22m
そこで、相手のアドレスをタッチすると、相手の連絡先が表示され、証明書に関する記述も書かれています。
IMG_2597m
「証明書を表示」のリンクをタッチすると、相手の証明書が表示されますので、「詳細」を表示などして、内容をざっと確認して「インストール」をタッチするとインストールされます。
IMG_2598m
IMG_2610m
以上で送信先の証明書を登録することができました。

iPhoneからS/MIME署名暗号メールを送る

先ほど証明書を登録した人に新規にメールを送ってみます。宛先にメールアドレスを入力すると、最初は青い錠前は開いている状態です。
IMG_2613m
青い錠前をクリックすると、無事「暗号化済み」と表示されています。あとは送信ボタンを押すだけです。
IMG_2614m
パソコンのOutlookで受け取ってみると無事、署名暗号化メールを見ることができます。
zzz07m

おわりに

以上、JCANのS/MIME証明書をいただいたので、iPhone標準メーラーのGmailアカウントに設定し、 署名暗号メールを送受信してみました。 すこし、登録などまどろっこしい所もあるんですが、AndroidではまともなS/MIMEメーラーは無いので、 iPhoneの標準メーラーはS/MIMEを「ちゃんと」使えて大したもんだなぁ、、、と思います。 今回の証明書はJCANさんのでしたが、英語の申請が気にならなければCOMODOからも 無料のS/MIME証明書を発行してもらえます。よかったらトライしてみてください。

これで、Googleはユーザーのメールの内容を監視していたりするんでしょうが、安心してムフフなメールのやり取りを他の人には決してみられることなく送れるわけです。いや〜〜、素晴らしいですね。

Gmailアカウント用のS/MIME証明書を欲しかったのは、実は GoogleのG-Suite Enterpriseではサーバーに秘密鍵と証明書を設定して クラウド型でS/MIMEの署名暗号メールが使えるそうで、それを使ってみたかったというのが あります。最近、インシデント対応に追われてなかなか時間が取れないんですが、 なんとか時間作って試したいなぁと思っています。 ではでは。

関連記事

Amazon AWSの認証局が少し怪しい件

Amazon AWSのELBとCloudFrontで使えるらしい、無料の証明書発行サービスで、AWS Certificate Manager(ACM)というのがあるそうです。([参考1])。ちょっと気になったきっかけはJavaからHTTPSで繋ぐと検証失敗するケースがあった


というので、ちょっと見始めたらドツボにはまったので、少しメモを書き残しておこうかとおもいます。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Javaで繋がらないとなると、ルート証明書や中間CA証明書が入ってないんだろうと疑ってみるとおもいます。 とりあえず、ブラウザで繋いだりしてみました。Windows 7のChromeやIEだとこんなパス。
view-ch-ie
Mac OS X(や多分iOSも)だとSafariでもChromeだとこんなパス。
safari-view
FirefoxだとOSによらず、WindowsでもMac OS Xでもこんなパス。
view-ff-chain
クライアント毎に使われている信頼するルート証明書が違うようです。 Starfieldルートになっているケースもありますね。 調べてみると、AmazonはGoDaddyからStarfieldルート認証局を一つ買ったのだそうです。

ACMの証明書を使ったサイトにブラウザで繋いでみると、、、

Amazonの証明書発行サービスはAmazon Trust Servicesというのだそうで、 証明書ポリシ、認証実施規程などの文書、ルート証明書、中間CA証明書などが置いてある リポジトリはこちらにあるようです。

リポジトリをよく見てみると、クロス証明書(片方向相互認証証明書、中間CA証明書)の リストがあるんですが、ハッシュと証明書のリンクが張ってあるだけで、大した説明もなく えらく不親切なページですよね。 認証局の構成がよくわからなかったので、これを元に図にしたのがコレです。(かなりの力作だとおもいます。)
ca-structure

なんかCAの鍵使いまわしてないですか?

このクロス証明書のリストで気になったのが、各Amazon Root 1〜4に対して、origとそうじゃないやつ、Starfieldに関してはv2とそうじゃないやつがある所です。 例えば、Amazon Root 1のorigとそうじゃないやつを比較してみると 以下の3点が違うだけで、

  • シリアル番号が違う
  • notBeforeが違う(origが2015年10月で、orig無しが2015年5月)
  • authorityInfoAccess拡張のcaIssuerのURLが少し違う。 http://{crl,crt}.rootg2.amazontrust.com/rootg2.cer となっている。origがcrlで、origなしがcrt。
とほとんど同じで、caIssuerを直したいだけのつまらない理由のために、中間CA証明書を再発行したようです。 これって中間CAの鍵を使いまわしてますよね。マズくないんですかね? さらに問題なのは、
  • どちらが正しい証明書なのかわからない。
  • ファイル名からはorigが古いように見えるが、 notBefore的には逆にorigが新しいようにも見える。
  • どちらか一方を失効しているわけでもなく、どちらも有効。
  • パス検証としてはどちらを使っても検証成功となるが、そんな事でいいのか?
  • 将来、{crl,crt}.rootg2.amazontrust.comのいずれかを無くす計画があると思うが、 それが明らかになっていない。
といった所です。 ちなみに、caIssuerに記載されたURLは、今の所はどちらもアクセス可能なようです。 両方にアクセスできるなら、なおさら中間CA証明書再発行の必要があったんですかねぇ? 単に、DNSの別名、CNAMEレコードの設定だけの問題なんじゃないですかねぇ。 また、本当はどちらに寄せたいと思っているのかも明らかにされてませんよねぇ。

同様に、Starfield Class 2 CAからStarfield Services Root CA G2に発行している 中間CA証明書も怪しくて、シリアル番号とnetBeforeだけが違う証明書があります。 どちらも失効していません。 こんなことして大丈夫なんですかねぇ? 最近、Certificate Transparency(CT)でSSLサーバー証明書全ての発行履歴残されており、 (私は最初はCTは嫌いだったのですが、) 認証局が問題あると、 (シマンテックのように、、、、) いろんな人が指摘してくれます。 中間CA証明書の発行についても、CTログに残しておかないと、 ヤバイ運用があるんじゃないかなぁ、、、、と思います。

Amazonの認証局はWebTrust認定もしており、Ernst Youngが監査しているそうですが、 こんなんで本当に大丈夫なんですかね?

Java 8?のcacertsのaliasについて

Amazon AWSやACMとは全く無関係ですが、最近自分は、Javaはめっきり触らなくなってしまい、今回の件でかなり苦労しました。Javaの信頼する認証局のためのキーストアファイルであるjre/lib/security/cacertsファイルなんですが、中のファイルを取り出そうとすると、そんなファイルは無いと怒られてしまいました。 よく見ると使ってみた新しい8u121では、aliasはこのようになっており、

% keytool -list -keystore jre/lib/security/cacerts   :中略 globalsigneccrootcar5 [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 1F:24:C6:30:CD:A4:18:EF:20:69:FF:AD:4F:DD:5F:46: 3A:1B:69:AA starfieldservicesrootg2ca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 92:5A:8F:8D:2C:6D:04:E0:66:5F:59:6A:FF:22:D8:63: E8:25:6F:3F ttelesecglobalrootclass2ca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 59:0D:2D:7D:88:4F:40:2E:61:7E:A5:62:32:17:65:CF: 17:D8:94:E9 addtrustqualifiedca [jdk],2016/08/26, trustedCertEntry, 証明書のフィンガプリント(SHA1): 4D:23:78:EC:91:95:39:B5:00:7F:75:8F:03:3B:21:1E: C5:4D:8B:CF   :後略
例えば「starfieldservicesg2ca」だけではだめで、表示されている通り「starfieldservicesg2ca [JDK]」のようにちゃんと[JDK]までつけないといけなくなったのだそうです。知らなかったし、ハマりました。

GWなもんで、今日はこんなとこで。

参考リンク

A look at AWS Certificate Manager
ACMを使い始めるときに参考になる。ACMを使ったサイト。
Free SSL With Amazon’s AWS Certificate Manager (ACM)
ACMを使い始めるときに参考になる。(その2)
ACM FAQ
公式サイトのFAQ
最新記事
Categories
Archives
記事Google検索

本ブログ内をGoogle検索
Twitter
Yahoo!アクセス解析
Travel Advisor
QRコード
QRコード

  • ライブドアブログ