適切な暗号スイートを選択する: BetterCrypto.org

SSLの暗号スイートはApacheなどのデフォルト設定を使えば安全と信じたいところなのだが、RC4の危殆化に伴って、RC4を無効にしないといけなかったりやPRISM問題が発生してPFSを有効にしたりと暗号スイートを自分で設定しないといけないパターンが増えてきたと思う。
(もちろんディストリビューションがデフォルトの暗号スイートを変更するのを待つという手もあるのだが、)

しかし自分で暗号スイートを選択して設定するのは困難だ。
僕は暗号の専門家ではないのでどの暗号が危殆化してないかとか、どの暗号を使うのが最適かとかを適切に選択できる自信はない。
かといって、適当にGoogleで出てきたApacheのSSLCipherSuite設定をコピペするのも不安だ。

そんな心配を解決してくれるのは、BetterCrypto.orgというサイトである。
オーストリア版CERTの中の人が、最新の安全な暗号スイートを簡単に設定出来るように常にアップデートしてくれている。

ApacheのSSLCipherSuite設定にサイトに記載されている暗号スイートをコピペすれば簡単にPFSなどを設定出来る。

オーストリアのCERNの推奨する暗号がセキュアかどうか信用できないから、自分でセキュアかどうか調べたいという人は、CRYPTREC電子政府暗号推奨リストを参照するとよい。
CRYPTRECとは総務省・経済産業省・NICT・IPAで構成された暗号の安全性・実装性について客観的に評価する組織で、様々な暗号を電子政府推奨暗号(今使える暗号)・推奨候補暗号(今後使う可能性が高い暗号)・運用監視暗号(危険なので使ってはいけない暗号)1 に分類してくれている。

セキュリティは沼なので逃げたくなるときもあるが、簡単に安全な設定をする方法(しかも安全性が検証された形で)が提示されはじめているので、そういう情報だけでもチェックしておくと良いのかもしれない。

  1. 括弧内の表現は目安として書いただけに過ぎないので、分類の詳細はきちんとCRYPTRECのサイトを参照してください []

HTTP/2における明示的プロキシ(Explicit Trusted Proxy)について

先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。

セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。
そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介+僕の思いを書きたいと思います。

[訂正]
私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。
しかしこの通信が暗号化されるべきかべきでないかの情報も秘匿すべきという考えもあり、私個人の考えとしてはhttp/httpsいずれのschemeにおいてもALPN Protocol h2を用いた方がよいと考えます。

背景

NSAによるPRISMプログラムの発覚以降、インターネットを取り巻く状況は大きく変化しました。政府によりインターネットは監視され、end-to-endにおける暗号が再び注目されるようになり、Twitterがたとえ将来秘密鍵を政府に奪われたとしても過去の暗号通信を復号されないようにEphemeral Diffie-Hellman鍵交換を用いてPFS(Perfect Forward Secrecy)に対応した話などを目にしたことがあると思います。1

更には先週IABとW3CによるInternet Pervasive Monitoring(大規模モニタリング)に関する共同ワークショップ STRINT Workshopが開催され、Opportunistic keying2 について取り組もうという話が出るなどエンド間における暗号の重要性が高まっています。

話を戻して、HTTP/2の前身であるSPDYはTLSによる暗号化を必要としています。これは元々ファイアウォールやロードバランサーなどのmiddleboxがSPDYなどの未知のプロトコルをブロックするが、TLSはブロックされにくいことからTLSを用いたのが始まりでした。HTTP/2でもそれを受け継ぎ、TLSを利用してプロトコルのネゴシエーションを行っています。TLSを用いてmiddleboxによるブロックを防ぐということは、middleboxにより通信内容を解析されることが困難になることから、PRISM事件以降たびたびHTTP/2において暗号通信を必須とする提案(httpであったとしてもTLSを必須とする)がなされてきました。

TLS(暗号化)がなぜダメか

HTTP/2でTLSが必須となり、すべての通信が暗号化されることにより、弊害が生じるという意見があります。様々な理由により、http通信を”最適化”・”効率化”しなければならないという意見です。例えば、

  • ペアレンタルコントロール
  • ウィルススキャン
  • ISPが転送量を減らすためにCDNを展開していないWebサイトの画像や動画などをキャッシュ(Transparent Proxy)
  • モバイルネットワーク特に衛星網など遅延が著しい環境において、画像の圧縮などを行い高速化
  • モバイルにおいて加入者情報をコンテンツプロバイダに提供
  • 最適化広告
  • エンタープライズにおいて、従業員が機密情報を社外に送信していないか監視
  • ISPによる自主的・法的問わず、児童ポルノ・違法コンテンツの流通の監視
  • 政府による合法的な市民の検閲・監視(Lawful interception / 合法的傍受)

などの理由3により、TLSによる暗号化をすべきでないという意見があります。

このような意見からHTTP/2ではTLSを必須とはしない決定がなされました。つまり、httpにおいては今までと同様に平文で通信が行われることになります。(もちろんhttpsではTLSを用いて暗号化されます)

Explicit Trusted Proxyの提案

httpでは平文を使うため、先に挙げた理由などでHTTP通信を”最適化”・”効率化”することは可能です。しかし、前回バンクーバーで行われたIETFでも大規模モニタリングはプロトコルに対する攻撃であり、プロトコルは大規模モニタリングに対して策を講じなければならないと決まる4 など、可能な限り暗号化もしくは安全なプロトコルを利用しようという動きは加速しており、HTTP/2においてもTLSは必須ではないですが、おそらく多くのコンテンツプロバイダーはhttpsを用いることが予想されます。

ほとんどの通信がTLSを用いて暗号化されてしまうと、先に挙げたHTTP通信を”最適化”・”効率化”することが難しくなってしまいます。そこでEricssonやAT&Tにより、TLSを用いていたとしてもユーザの明示的な同意があればプロキシによるMITM5 を可能とする提案(draft-loreto-httpbis-trusted-proxy20)がなされました。

HTTP/2ではTLSのALPN6 というメカニズムを用いてTLS上でどのプロトコルを使用するかネゴシエーションを行います。HTTP/2の場合クライアントはh2というIDを通信可能なプロトコルとしてサーバに提示することでHTTP/2で通信が行われます。提案ではクライアントはh2clrというIDを提示している場合、中間に存在するプロキシがそこで通信を終端し、ユーザの明示的な同意(SHOULD)の後、”最適化”・”効率化”を行うことを可能としています。

提案では中間に存在するプロキシはその際拡張キー利用法にproxyAuthenticationが含まれたSSL証明書を用いなければならないとされており、より高いセキュリティが必要な場合はEV証明書を使うことを推奨しています。

ユーザが同意しない場合、プロキシはTLSのClientHelloメッセージをサーバに送信することでサーバとクライアント間でTLS接続を終端するとされています。

ユーザの明示的な同意とは

公衆無線LANなどにおけるCaptive Portalの場合など、提案ではさまざまなケースについてどういうフローを取るべきか書かれています。

また提案では、ユーザが同意した場合、ユーザエージェント7 は同意したという情報を保存し、次回以降同意無しにプロキシに接続しなければならない(SHOULD)とされています。一方提案ではその同意は特定の接続に限定されなければならなず(SHOULD)、一定の時間もしくは一回のみに限定することができる(MAY)とされていますが、特定の接続についての定義については述べていません。

しかしユーザの明示的な同意とは何をさすのでしょうか?

例えば「お客さまの通信速度の向上のため、通信の最適化を行います」と表示されたら大抵のユーザは同意ボタンを押すでしょう。しかし、本当に行っているのは安全なはずの暗号通信をman-in-the-middleする以外の何者でもない話であり、ユーザがhttpsで、アドレスバーが緑色だから安全と信じて入力したパスワードやパーソナルデータは実は”通信の最適化”のため中間者によって復号されているわけです。そして一度同意してしまったら明示的に設定をオフにしない限り、安全であるはずの通信が第三者によって見られ続けることになります。

また同意がプロキシ側で行われるのは更に問題です。この提案ではコンテンツプロバイダー側がプロキシを禁じることはできないため、プロキシが攻撃された場合ユーザ・コンテンツプロバイダー双方が気付かない間に情報が盗まれる可能性があります。

僕はこれは極めてunhealthyだと思います。

httpsを使う限り安全である8 通信が、httpsを用いていても安全ではない、安全かどうか確認することが非常に煩雑になってしまいます。これではHTTP/2はHTTP/1.1に比べて後退してしまいます。

じゃぁどうすればいいの?

通信の秘密・言論の自由は憲法・電気通信事業法で保障された国民の権利です。一方子どもの権利は優先されるべき権利であり、それらを犯す児童ポルノなどを規制しなければならないことも理解できます。どちらも僕らの社会を支えるとても大切な権利だと信じています。

僕自身答えは持ち合わせていません。

いくつかのユースケースに対しては他のアプローチにより問題を解決することは出来ます。たとえば、キャッシュの問題ではキャリアがCDN-likeなサービスを安価で提供し、コンテンツプロバイダーが利用することで暗号化されるべき情報のみコンテンツプロバイダからサーブされ、画像などはCDNから配信するようなアプローチです。

しかしHTTP/2の持ち合わせるパフォーマンス改善など華やかな部分が取りただされている間にこの提案がなされ、静かにしかし確実に僕らのインターネットを変化させようとしていることを見逃してはいけないと思っています。

この問題はHTTP/2だけではありません。たくさん議論をしても皆が納得する結論を導くのは難しいと思っています。

コメント欄でもTwitter上でもかまいません。いろいろな意見をいただけるとうれしいです。

Natashaもこの問題を英語でも書いてくれています
Pervasive Monitoring, HTTP2, TLS: Why Can’t the User Decide?

免責事項

  • この記事は私の視点であり、所属するいかなる組織の意思を示すものではありません
  • 私はネット中立性・インターネットの自由・通信の秘密・表現の自由を支持しています
  1. PFSについての解説と、なぜPFSが重要かは、Lavabit 事件とその余波、そして Forward Secrecyに書いてあるので見てみてください []
  2. 日和見暗号・Opportunistic Encryptionとも。httpsなどは暗号通信を行うことが明示的に同意されているが、httpなど明示的には暗号通信を行わない通信においてもエンド間が暗号を利用できる場合、暗号を利用することで安全に通信を行おうという考え []
  3. 詳しくはhttp2 Githubに記載されたProxy-use-caseを参照: Proxy User Stories · http2/http2-spec Wiki []
  4. Pervasive Monitoring is an Attack: https://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ []
  5. Man-in-the-middle: 中間者攻撃 []
  6. Application-Layer Protocol Negociation: 詳しくは@flano_yukiさんによるALPNについての解説を参照 []
  7. User-Agent: ブラウザのこと []
  8. PRISMの例や、httpsでも弱い暗号を使っていて第三者に解読される場合などはありますが []

JALの国内線で機内WiFiが使えるようになる話

2014年夏から国内線でも機内WiFiが使える様になるそうだ!1

JALの国際線では去年の夏から機内WiFiが使える様になってすごく便利なんだけど、機内WiFiは主に2つの方法で航空機と地上とを結んでいるので紹介。

  1. Kuバンド帯を使った衛星による通信
    Kuバンドという衛星通信でよく使われる周波数帯(12-18GHz)を用いて航空機と衛星、衛星と地球局(つまり地上)と結んでインターネット接続を可能にする方法。
    この方式だと衛星に接続出来る範囲(要リサーチ)がかなり広いので、ほとんどのエリアをカバーすることが出来る。2
    欠点としては衛星を経由するのでコストがかかる。(衛星の資源は限られてるからね)
    そして地球局はあまり分散されていないので、インターネットネットワーク的に不効率な場合が多い。
    例えばJALやトルコ航空などはT-mobile DEを地球局にしているので、日本の上空に居ても
    [航空機]-[衛星]-[地球局(ドイツ)]-[日本のWebサイト]
    みたいになって通信が非常に遅くなる。
  2. Air-To-Groundによる通信
    これは衛星を使わずに航空機と地上を結びインターネット接続を可能にする方法。
    簡単に言ってしまうと地上にアンテナを設置してそれと航空機が通信する感じ。
    今回JALが提携したgogoはATG-4というネットワークを米国国内に展開していて、160以上の基地局を設置している。
    航空機と基地局の間はEV-DO Rev.B(つまりCDMA-2000)で繋がっている。まさに携帯電話の電波を空に向けて出しているような方式。
    これだと衛星を使わずに済むので、安価にネットワークを作ることができる。
    しかし海上などでは基地局を設置できないのでネットワークを作ることが難しい。

今回JALがgogoと組んだので、てっきりATGでネットワーク組むのかと思ったのだが、中の人からリプライ貰ってどうもKuバンドで組むらしい。海や山が多い日本では基地局を設置するよりも衛星の方が良さそうですよね。3

どちらの方式にもメリット・デメリットがある。
アメリカのような国ではATGは良さそう。海が多い国では衛星。

飛行機に乗ってる間ぐらいしかオフラインになれないのにネット導入するとはむきー!!っていう話も非常に理解できるんですが、個人的にはネット有れば機内で暇にならないので早く導入してほしいなと思っています。

p.s.
ところで青い航空会社はいつになったら国際線に機内WiFi導入してくれるんだろう。。。
一応2013年の夏導入開始って話らしいんだけどね。。。げほげほ4
あ、なんか特定の便ではロールアウトしてるって話も聞くけど中の人こっそりおしえてください。

  1. 国内線においても「JALの新しい空 」が始まります - https://www.jal.co.jp/inflight/dom/new_seat/ []
  2. ただ成田-ニューヨークでも3,4個の衛星をハンドオーバーしてるらしい - https://www.ituaj.jp/wp-content/uploads/2013/04/2013_05-3_spsky.pdf []
  3. https://twitter.com/Gogo/status/394880907003580416 []
  4. ANA国際線機内で、Wi-Fiサービスがご利用できるようになります - http://www.ana.co.jp/pr/12_0406/12-ana-onair0625.html []

KDDI版iPhone 5/5s/5cでIPv6をつかう

ついにiPhoneでIPv6が使えるようになった!

20130927-161641.jpg

iPhoneにおけるiPv6はiOS 6時代からサポートされており、VerizonではiPhone 5からサポートされていた。これはVerizonはLTEにおいてIPv6をオプションではなく必須テクノロジーとしたためである。1

そのため、iPhone 5以降iOSデバイスはIPv6をサポートしているのだが、Carrier Bundleの設定で有効にされているキャリアと有効にされていないキャリアが存在する。

CarrierBundle内のRequiresIPv4v6PDPTypesがTrueになっている場合に対応するのだが、KDDI Carrier Bundleでは15.1からサポートされ、Carrier Bundle的には対応した。

しかし現実にはこれだけでは動くわけではない。APN側でIPv6アドレスを払い出さない限り使用することができない。KDDIではLTE NET for DATA2というISPサービスでグローバルIPv4/IPv6アドレスの払い出しを行っている。
上記ページにはiPhone, iPadは対応していない旨が書かれているが、実際はAPNを書き換えることで動作する。

そこで、APNをLTE NET for DATAのau.au-net.ne.jpに書き換えることで、IPv6での通信が可能となる。

構成プロファイルを使うことで自分でも設定することが可能だが、実際に動作を確認したプロファイルを置いておくのでもし良かったら使ってください。
KDDI_iPv6_enabler : https://nunnun.jp/src/KDDI_iPv6_enabler.mobileconfig

追記: KDDIのホームページにやり方書いてあった。(いつの間に!)kazubu thanks!!
LTE NET for DATAの利用方法

手元の端末ではiPhone 5 / iPhone 5s / iPad miniで試してテザリング含めて動作することは確認しました。

  1. IPv6 at Verizon Wireless []
  2. http://www.au.kddi.com/mobile/charge/list/ltenet-for-data/ []

iOS 7でMPTCPがサポートされた話

iOS 7でMPTCP(Multipath TCP)がサポートされた。1
唐突2なのだが僕の博士課程における研究テーマであり、先のIETFで大人たちにメッタメタにされたのも悔しいのでMPTCPについて説明して、何が出来るようになるかを書きたいと思う。

MPTCPとは簡単にいうとTCPストリームを複数の経路で転送することにより、ストリームの多重化・耐障害性の向上を図るプロトコルである。

このタイミングでなぜこうしたプロトコルが必要か簡単に説明したい。
僕らが使うアプリケーションは大抵TCPを用いて通信をしている。それは長いインターネットの歴史でもあり、順序制御・再送制御・誤り制御をトランスポート層のプロトコルが行うことにより、僕らはそういったことを意識せず済むからである。
TCPはIPおよびポート番号を用いてストリームを識別する。例えばsrc: 192.168.0.1:3208 dest: 192.168.0.2: 63234といった形だ。そのためIPアドレスやポート番号が変更されると通信を継続するにはTCPストリームを再接続しなければならない。

話を変えて僕らが持つスマートフォンは大抵3GとWiFiという2つのIPインターフェイスを持っていることが多い。TCP・UDPでは1つのストリームにおいて複数のIPアドレスを用いることが出来ないため、通常どちらかのインターフェイスを優先的に使用するように制御されている。例えばWiFiが有効な環境においては新規のTCPストリームはWiFiのIPアドレスを用いて通信するなどだ。
この発想はインターフェイスが頻繁に変更されない場合有効である。しかし、インターフェイスが頻繁に接続・切断を繰り返しインターフェイスのスイッチが頻繁に発生するような場合(例えば公衆無線LANが入り乱れる都心の市街地を歩いているような場合)においてTCPセッションはインターフェイスが切り替わる度に再接続を行わなければならない。
TCPは僕らが生まれる前(1982年)に発明され、その当時の不安定な回線において信頼できる通信を行うために、3-way handshakeを必要とする。3GやWiFiなど遅延が大きなネットワークにおいてただただ通信を開始するためだけにパケットを往復させることは通信に大きな遅延を引き起こす。これが市街地において特に移動中公衆無線LANが全く使い物にならない原因の一つである。
(もちろんWiFiのイニシエーションにも時間がかかるので、それを早くしようという802.11aiなどもあるがこれは後日)

そこでTCPが持つ1つのIPアドレス・ポート番号でバインドされた経路しか使えない状況を改善し、複数の経路を用いてTCPのような通信を可能にしようという取り組みがなされてきた。
SCTPはPoint-to-point のプロトコルであるものの、エンドホストが複数のアドレスをサポートするため、エンドホストに到達するために複数のアドレスを使用することが可能であり、それにより下層レイヤー(つまりIPインターフェイス)の切替といった場合にもストリームが切断されることなく通信が可能なプロトコルである。
またMobile IPやMobile IPv6といったIPレベルでの取り組みもなされた。Mobile IP/IPv6はホームアドレスと呼ばれる移動をしても変化しないアドレスを用いることでインターフェイスが切り替わりネットワークをハンドオーバーしてもTCPやUDPなどIPアドレスをキーとして依存するプロトコルの切断を防ごうという取り組みである。
さらにはもっと低いレイヤーで3G/WiFiのハンドオーバーといった研究開発が行われてきた。

しかしながら、今日現在いずれのプロトコルもliftすることができていない。
なぜなら僕らはTCP・UDPをから逃れることができないからだ。
現在僕らがインターネットで使う殆どのプロトコルはトランスポートにTCP/UDPを使用して、インターネットもTCP/UDPを前提に設計・運用されている。例えばIPv4アドレスを共有する手法としてNATがあるが、NAT自体TCP/UDPに特化していて(もちろんGREとか対応しているのもあるけど) いくらTCPが先に述べたような問題があったとしても星の数ほどあるNAT-boxをSCTPに対応させるということは不可能である。
また3G/WiFiのハンドオーバーなども3G/WiFiいずれも同じネットワークオペレータが運用するといった場合には実現が可能でも、今日のインターネットような様々な組織が様々なネットワークを運用する形態においてはなかなかdeployすることが難しい。(技術的にもポリシー的にも難しい)

そんな中TCPを殆ど改変せず複数のストリームを扱えるようにしようという発想で提案されたのがMPTCPだった。
プロトコルの詳しい説明はきちんとまとめて記事にしたいので控えるが、MP_CAPABLEと呼ばれるTCPオプションを用いてエンドホストでnegotiationを行い、双方がそれをサポートする場合に限り2つ以上の経路を用いて通信を多重化し、下層レイヤーの障害の影響を受けずにTCPセッションを維持することが出来るTCPの拡張プロトコルである。
このMP_CAPABLEなどの処理はOSなどに実装されたTCP実装が透過的に行うため、アプリケーションからは普通のSocketと同じように利用することが可能である。つまり既存のアプリケーションを変更することなく、自動的に複数の経路を用いて障害に強く、多重化されたTCP通信を行うことが出来る。SCTPなどはアプリケーション自体の書き換えが必須であったことを考慮すると非常に有効であるといえる。

TCPオプションという話をすると必ず問題になるのがmiddleboxである。
理想的な環境ではインターネットを流れるパケットは改変されることなくエンドに転送される。しかし、現実のインターネットではNATやファイアウォール、更にはアプリケーションアクセラレータなどパケットを改変する中間者が大量に存在する。
MP_CAPABLEなどの未知のTCPオプションが存在する場合、そうしたmiddleboxはパケットを破棄したり、TCPオプションの破棄などを行うことが指摘されている。3
そこでMPTCPではそうしたmiddleboxが存在している場合でも通信を行えるような仕組みや、最悪の手段としてTCPにフォールバックする仕組みが存在している。4

前振りが長いが、で、MPTCPがiOS 7でサポートされて何がインパクトが有るか。さーっと考えてみた限りこんなインパクトが考え得る。

  • 3G/WiFiのハンドオーバーがスムーズになる
  • 優先制御が可能であるため、回線の重み付けが可能にある
    ここでは説明していなかったが、MPTCPでは経路毎の優先制御が可能である。
    例えば3G:10%, WiFi:90%といった具合である。この場合もWiFiが切れても自動的に3Gで再送が行われるため、TCPセッションは切れることがない

現時点ではLinuxとfreebsd, iOS7でしか実装されていない。
GoogleはRTTの影響を受けにくいプロトコルとしてUDPをベースとしてQuicを提唱している。Quicももちろん有効に働くと思うが、Quicの場合アプリケーションの書き換えが必要になる。
MPTCPはカーネルにおいて処理されるため、アプリケーションの書き換えなしにストリームの多重化が可能になる。もちろんどちらのプロトコルが優位であるという議論をしたいわけではない。

iOS 7ではまずはSiriでMPTCPが有効にされているという話だ。
ユーザの音声データをなるべく早くサーバに送信したい(でも失敗したくない=再送は時間がかかるのでUXに影響がでる)ので、WiFi/3Gの両方を使うことで確実に早く転送したいというケースで、MPTCPのユースケースとしては非常に優れていると思う。

記事でも指摘されていたがこれから他のアプリでも有効になるのではないかと思う。
MPTCPはサーバでも有効にされて初めて効果がでるプロトコルなのでこれからサーバ側の実装も必要になる。まだまだユースケースも少ないプロトコルなので、標準化や研究にうまく結びつけていきたいなと思う。

ここは間違ってるとか、補足すべきことがあるとかあったら指摘していただけるとうれしいです。

  1. Apple iOS 7 surprises as first with new multipath TCP connections []
  2. しかし実はIETF87で、anonymous OSが実装しているという話もあり、iOS 7がそれだったのかと納得した訳だが []
  3. Is it Still Possible to Extend TCP? Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley and Hideyuki Tokuda, ACM Internet Measurement Conference (IMC), November 2011, pp.181-192, Berlin, Germany []
  4. How Hard Can It Be?! Designing and Implementing a Deployable Multipath TCP []

マジキチなのでiPhone 5Sのために徹夜した

au版ホワイト 64GBをゲットしたので満足している。
ただMNP予約番号を取り消さないと手続きできないという罠にハマって待機中。

ドコモ、ドコモってみんな話してたのに全く並んで無くてワロタ。

ゴールド個人的には微妙。。。グレーは在庫いっぱいだし質感良いしいいかも。

沖縄からこんにちは

5年以上ぶりに家族旅行で沖縄に来てもblogを更新を続けるアカウントがこちらになります。

海はきれいだし、美ら海水族館に行ってイルカショーみて満足だし、ダイビング潜って大満足なんですが、ばっきゃろーBuffaloさんのiPhone 5防水ケースに入れてたら浸水してiPhoneがお亡くなり疑惑に・・・。(幸い速攻気付いて乾かしたのでたぶん平気・・・だけど海水だし・・・
DSC00163DSC00295DSC00305