How New CSS Is Changing Everything About Graphic Design on the Web
その｢s｣を付けるために 〜はてなブログHTTPS化の軌跡〜 / Rejectcon 2018 - Speaker Deck
How New CSS Is Changing Everything About Graphic Design on the Web
Chrome58で、HTTPSの自己証明書が NET::ERR_CERT_COMMON_NAME_INVALID になる場合の対応
Chrome58で、HTTPSの自己証明書が NET::ERR_CERT_COMMON_NAME_INVALID になる場合の対応 Google Chrome をバージョン58 にアップデートすると、SSL自己証明書を使っているサイトが見れなくなる場合があります。 自己証明書(オレオレ証明書)を使っているサイトに HTTPS でアクセスすると、 この接続ではプライバシーが保護されません 攻撃者が、tech.torico-corp.com 上のあなたの情報（パスワード、メッセージ、クレジット カード情報など）を 不正に取得しようとしている可能性があります。 NET::ERR_CERT_COMMON_NAME_INVALID セキュリティに関する事象についての詳細を Google に自動送信する。プライバシー ポリシー セキュリティで保護されたページに戻る詳細情報を表示しない このサーバーが
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景 WebサイトをHTTPS化する最も大きな理由は、インターネットの信頼性を維持することです。TLS技術の現状や、安全なHTTPS化に何が必要かを、ヤフー株式会社の大津繁樹氏が解説します。 「SEO対策のためには、WebサイトをHTTPS化しないといけない。」 —— そう聞かされて対応を迫られている技術者の方も多いのではないでしょうか？ 確かに、Googleは「HTTPSページが優先的にインデックスに登録されるようになります」と表明し、HTTPS化されたWebサイトが同社の検索結果で有利になると示唆しています。はたして、WebサイトのHTTPS化が必要な理由は、SEO対策だけなのでしょうか？ そして、それはGoogleという一社だけの意向で推奨されていることなのでしょうか？ こうした疑問に答
Google Public DNS over HTTPS を試す | IIJ Engineers Blog
【2018/11/16 追記】 本記事は、2016 年 4 月に Google Public DNS サーバに実装された、実験的な DNS over HTTPS プロトコルについて紹介しています。DNS over HTTPS プロトコルはその後 IETF の doh ワーキンググループにて標準化が進められ、2年半後の 2018 年 10 月に RFC8484 として出版されました。本記事で紹介したプロトコルは RFC8484 に規定されたプロトコルとはいくつもの点で異なっていることにご注意ください。 Google Inc. が公開 DNS サーバを運営していることはご存知でしょうか? Google Public DNS と呼ばれるこの公開 DNS サーバは、”8.8.8.8″ という特徴的な IP アドレスで全世界のインターネットユーザに対して無料の DNS サーバ(フルレゾルバ)を提供し
社内プロキシに虐げられてる人たちはVPSとか借りて社外にプロキシ立ててsshトンネルで繋ぐとウハウハですよってお話 - Qiita
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
SSL - 【SSL】業務システムには、CA署名型or自己証明型 どちらが適していますか？｜teratail
社内業務システムをWebに移行中です。 それに伴いSSL暗号化を考慮しています。 社内システムの場合、 第三者が発行するCA署名型と、 自分で発行する自己証明型の どちらが一般的でしょうか？ 金銭的なメリット以外に、自演できる自己証明型のメリットが今一つ分かりません。 社内業務システムでは、利用者が社内の従業員に限定されるので 自己証明型でも良い、という考え方もあるでしょうか？ なにぶん初めてなもので、この辺りのご意見いただければ幸いです。 どうぞ宜しくお願い致します。
Caddy という高機能 HTTPS サーバー
https://caddyserver.com/ なにやら大変便利そうなものがありました。 HTTP/HTTPS サーバーTLS 証明書の自動更新が可能 (HTTP, DNS 両方対応)HTTP2, QUIC, WebSocket にも対応Go で書かれているのでマルチプラットフォーム対応単純なディレクトリの公開Markdown のレンダリングが可能ダイナミックな証明書取得 (Let’s Encrypt はワイルドカード証明書に対応していないが、リクエストを受けた時点でそのドメインの証明書を取得するということでワイルドカードっぽく使える)リバースプロキシロードバランスBasic認証他Plugin による拡張IPアドレス制限ratelimitファイルアップロード、削除CGIなどなどhttps://github.com/caddyserver/examples ここに各種設定例があります。でも
CertbotでDNSによる認証(DNS-01)で無料のSSL/TLS証明書を取得する - 本日も乙
[toc] Certbot(旧Let's Encrypt)は無料でSSL/TLS証明書を発行できる認証局(CA)です。有効期限が90日(約3ヶ月)と短いですが、コマンドによる自動化が可能で定期的に実行することで常に証明書を更新し続けることができます。 証明書を取得するにあたり、ドメインを自分で管理しているかの認証方式が以下の三つがサポートされています。 HTTP-01 Let's Encryptの認証局からワンタイムトークンを発行してもらい、Webサーバに認証用ファイルを設置する。 認証局からHTTP(80番ポート)でアクセスしてもらい、ワンタイムトークンと認証用ファイルとの妥当性を検証する。 TLS-SNI-01 HTTP-01と同じ方法だが、HTTPS(443ポート)を使用する。 DNS-01 Let's Encryptの認証局から発行してもらったワンタイムトークンを対象ドメインのTX
Apache 2.2.* 系と OpenSSL での HTTPS の利用 - Linux サーバ認証 編 -
Apache 2.2.* 系と OpenSSL での HTTPS の利用 - Linux サーバ認証 編 - ここでは、Apache 2.2.* 系と OpenSSL を使用して HTTPS 通信を行います。 サーバ認証について簡単に説明いたします。 一般的に HTTPS 通信 ( 通信経路の暗号化 ) を使用する場面というのは、 個人情報の送信や クレジットカードの情報などの送信において必要になると思います。 なぜ必要かというと、それらの情報は他に漏れてはいけない情報であり、もし平文で送信したならば、 途中の通信経路のどこかで第三者に、その情報を見られてしまう可能性があり、重大な結果を招きかねません。 そのような結果を防ぐ目的があり、HTTPS 通信を行います。 しかし、ここで以下の条件を満たす必要があります。 ・通信経路の暗号化 ・情報を送信するサーバが本当に実在し、自分が送
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How To Secure Your Rancher Web App with Let's Encrypt on Ubuntu 16.04 | DigitalOcean