今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景 WebサイトをHTTPS化する最も大きな理由は、インターネットの信頼性を維持することです。TLS技術の現状や、安全なHTTPS化に何が必要かを、ヤフー株式会社の大津繁樹氏が解説します。 「SEO対策のためには、WebサイトをHTTPS化しないといけない。」 —— そう聞かされて対応を迫られている技術者の方も多いのではないでしょうか？ 確かに、Googleは「HTTPSページが優先的にインデックスに登録されるようになります」と表明し、HTTPS化されたWebサイトが同社の検索結果で有利になると示唆しています。はたして、WebサイトのHTTPS化が必要な理由は、SEO対策だけなのでしょうか？ そして、それはGoogleという一社だけの意向で推奨されていることなのでしょうか？ こうした疑問に答
社内サービスを一括・即座・セキュアにリモートワーク開放した話 - エムスリーテックブログ
はじめまして。 エムスリーエンジニアリンググループSREチームの山本です。 先日来のリモートワーク促進の中、弊社でも多くの社員がオフィス外から接続するようになりました。 もちろん、VPNを利用すれば社内のサービスも利用できますが、VPNの使用量が一気に増えるとそちらの制限にかかります。 今回「VPNを可能な限り利用せず、なおかつセキュアに社内のサービスを利用してもらう」という課題に取り組みましたので、ここでその紹介をさせてください。 前提 方針 クライアント証明書の問題点 一括でのSSL化・証明書検証 ドメイン変換 実際の設定 Squidの設定(抜粋) unboundの設定 nginxの設定(クライアント証明書検証) nginxの設定(HTTPサーバに対するproxy) nginxの設定(個別対応) ブラウザのProxy設定 その後発生した問題 ポート問題 Hostヘッダ問題 戻りヘッダ問
S3のSSL通信 - Qiita
2019/07/11：コメント欄のご指摘を受け実験結果を一部削除。(HTMLのパスを間違っており変な実験結果を載せてました。お恥ずかしい・・・） S3は HTTPSをサポートしていない？ 「 S3は、HTTPS通信できないですよね？ 」と言う話しが会話ででてくる事がよくあり「あれ、実際HTTPS通信問題なく使えているのに、その話し良く聞くけどなんでだっけ」と思う事があるので、メモしておきます。(この記事中のテスト用のリンクは予告なく削除される事がありますのでご了承下さい) 結論としては、 S3デフォルト(「REST APIエンドポイント」)では HTTPS通信可能。 「ウェブサイトエンドポイント」としての設定(ドメイン名のフォーマットが「REST APIエンドポイント」と異なってくる)をした場合は、「ウェブサイトエンドポイント」用のドメインでは、HTTPS通信できない (但し、デフォルトで
S3にSPAはデプロイできるのか -HostingとRouting-
できます。 ここにある通り、S3 の設定ページで エラードキュメント に index.html をセットするだけで良いです。CloudFront がなくてもできます。 （完） ただ、たとえば /about でリロードして、404 Not Found になっていたものが、エラードキュメントに index.html を指定したら /about が見れるって違和感ありませんか？ 少なくとも私は「index.html に redirect するのだから、そこで見えるものって / なのでは！なんで/about が見えるんですか!？」という疑問を持っていました。 あと、「S3 SPA」で検索すると、CloudFront 前提だったり、index.html を書くことで解決される理由は書かれてなさそうなので、そういうのを解説したいと思います。 どうして SPA のホスティングで悩むのか SPA(Sing
CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
ALBのTargetGroup付け替え時にエラーになるリクエストは発生しないのか確認した | DevelopersIO
確認したいこと ALB（Application Load Balancer）のリスナーとして設定するTarget Groupは、随時変更することができます。変更したそのタイミングでアクセスがあった場合に、エラーになることはないのか、気になったので確認しました。 図で説明 この状態から この状態に変える瞬間に このようにエラーになってしまうリクエストが発生しないか 結論 大丈夫そうです。Target Group付け替え時にエラーになるリクエストは発生しないようです。 検証方法 httpingというpingのhttp版のコマンドを使って、ローカルからALBに対して断続的にリクエストし続けます。その途中でTarget Groupの付け替えを行なって、エラーになるリクエストが無いか調べました。 Target Groupには前述の図のように、それぞれ異なるEC2インスタンスが一台ずつ紐づいています。
【図解】よく分かるデジタル証明書(SSL証明書)の仕組み 〜https通信フロー,発行手順,CSR,自己署名(オレオレ)証明書,ルート証明書,中間証明書の必要性や扱いについて〜
デジタル(SSL)証明書とはデジタル証明書とは、あるサーバや NW 機器へ高セキュリティで通信するために使われる電子ファイルのことです。デジタル証明書は "認証局" と呼ばれる機能を持つサーバが生成します。 一番馴染みがあるのは http と併用する https (http oves SSL/TLS) での利用で、このときは SSL 証明書とも呼ばれます。 例えば『abc.example.com』というホスト名の Web サーバにデジタル証明書をインストールすると、https が使えるようになります。 そのためにはまず、"認証局 A" から『サーバ abc 用のデジタル証明書』を生成してもらう必要があります。 そのサーバ abc 用のデジタル証明書には『サブジェクト代替名 (DNS name)：abc.example.com』と記載されています。 デジタル証明書には公開鍵が含まれており、サ
ALBでhttpをhttpsにリダイレクトできるやつが便利だった - まーぽんって誰がつけたの？
今まではnginxでリダイレクトさせてた こんな感じでhttpでアクセスしてきたらhttpsにリダイレクトするっていうのをnginxの設定で書いてました。 if ($http_x_forwarded_proto != https) { return 301 https://$host$request_uri; } これで困るのは ALBからのhealth checkはhttpで来るので、health checkも301が返っちゃうということです。 で、例えばuser agentがELB-healthcheckerで、かつ、httpだったら301じゃなくて200返すとか書けばいいんですが、nginxでand条件のif文書くのは結構大変なのです。（プログラミング言語ではないのでそういうもの） こちらの記事を引用します。こんな感じになっちゃうイメージです。 Nginxで複数条件のIF文を書く方法
AWSでWebサイトをHTTPS化 全パターンを整理してみました
渡邊です。 今回は、AWSを利用してWebサイトのHTTPS化を行う方法は数多くあります。この記事では思いつく限りの全パターンをあげてそれぞれの特徴について解説していきます。 2018年7月からChromeは非HTTPSサイトで「安全でない」警告を表示 Googleは2018年7月にリリース予定のChrome 68から、すべてのHTTPサイトに「Not Secure(セキュアでない)」と表示を出す方針を発表しています。 https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html For the past several years, we’ve moved toward a more secure web by strongly advocating that sites adopt HTTPS enc
HTTPS通信の疎通確認に覚えておきたい３つのコマンド - Qiita
$ curl -s -v --sslv3 https://example.com 1> /dev/null * Rebuilt URL to: https://example.com/ * Trying 93.184.216.34... * Connected to example.com (93.184.216.34) port 443 (#0) * SSL peer handshake failed, the server most likely requires a client certificate to connect * Closing connection 0 おっと、SSLハンドシェイクで通信に失敗したようですね。SSL3.0はPOODLE脆弱性問題があります。ちゃんとexample.comでは無効にしているようですね。以下のようにTLS1.2ではきちんとできました。Di
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
