$ 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
安全なウェブサイトを公開するため、無料で利用可能な Let's Encrypt の証明書を使う方法をご紹介します。Let's Encrypt の背景とSSL証明書の自動発行をはじめ、CentOS 7 上の Nginx ウェブサーバを SSL に対応する方法、そして、証明書を自動更新する方法を見ていきましょう(所要時間10~20分)。 なお、Let's Encrypt については既に中津川さんの記事「すべてのWebサイトの暗号化を目指すLet's Encryptを試す」で取り上げられていますが、今回は新しいクライアント certbot-auto を使う方法や、証明書の自動更新の仕方をとりあげます。 こんにちは!こんにちは! みなさん、はじめまして。さくらインターネットの前佛雅人(ぜんぶつまさひと)です。さくらのナレッジに何か書け(業務命令)ということで、皆さんがサーバをより活用できるよう、ナ
ついに、インターネット技術タスクフォース(IETF)が RFC7469 HTTP公開鍵ピンニング拡張 (HPKP)を発表しました。このアイデアを出してくれた同僚のRyan Sleevi、Adam Langley、Chris Evansに感謝します。また、RyanとChris EはRFCの最終稿に先立つ大量のドラフトの執筆を助けてくれました。そして、ドラフトにコメントし、RFCとして公開できるまでにしてくれたIETFの多くの参加者にも感謝します。 ピンニングとは何か? 何を解決できるのか? HPKPは Web PKI の大きな問題の1つを解決する試みです。その問題とは、基本的に認証局(CA)や中間認証局は、どのWebサイトにもエンドエンティティ(EEまたは”リーフ”)証明書を発行することができてしまうことです。例えば、mail.google.comの証明書が”Google Internet
(初めに言い訳しておくと、証明書界隈については詳しくないです。某誤訳量産サイトが適当な記事を書いていたので、なにか書かねばと思って書いているという程度のまとめ記事です。間違いなどあればご指摘ください) 何が起こるのか Ryan Sleeviさん(Googleの人)がBlink-devのメーリングリストに投稿したこれにまとまっています:https://groups.google.com/a/chromium.org/d/msg/blink-dev/eUAKwjihhBs/rpxMXjZHCQAJ 経緯についてはいったん飛ばして、どのようなアクションが提案されているのか見ます。 To restore confidence and security of our users, we propose the following steps: A reduction in the accepted
git を https 経由で使う場合、pull や push のたびに毎回パスワードを聞かれてしまいます。 これを改善するには git-credential を使うと良いです。 git-credential は git 1.7.9 以降で使用可能です。 なお、古いやり方としては .netrc を使う方法もありますが、パスワードを平文でファイルに保存するので、やらないほうがいいと思います。 使用可能な管理方式 git-credential では、以下のような方法でユーザ名とパスワードを管理できます。 git-credential-store : ファイルに保存します。ただし、パスワードが平文が保存されます。 git-credential-cache : 常駐プロセスに記憶させます。 git-credential-osxkeychain : Mac OS X のパスワード管理を使います。 G
はじめに Set Up Git · GitHub HelpのNext steps: Authenticating with GitHub from Gitによると、GitHubへのアクセスはSSHよりHTTPSがお勧めらしいです。 OSXのキーチェーンにgitで使用するパスワード/アクセストークンを保存する設定 Caching your GitHub password in Git · GitHub Help 私はHomebrewでgitをインストールしているのでgit-credential-osxkeychainはインストール済みでした。 ということで、設定は以下のコマンドを実行するだけです。 この設定をしておくと、GitHubからgit cloneするときにユーザ名(メールアドレス)とパスワードを聞かれて、入力するとキーチェーンに保存されます。以降はパスワードの入力は不要になります。
以前、githubにsshポートが通らなくてもpush出来る方法をご紹介しましたが、今日はbitbucketです。 bitbucketは元々https経由でpush出来ますが、sshプロトコルを使わない場合はbasic認証になってしまいパスワードを毎回尋ねられます。またそれを省略しようと思うと、Clone URLを hg clone https://username:password@bitbucket.org/username/example といった感じにしなければならなく、とても危険です。 出来る事ならばsshを使いたいですね。実はgithubと方法はまったく同じ。 bitbucketのアカウントページにid_rsa.pubの値を貼り付け、ssh/configファイルを修正します。 ~/.ssh/config Host bitbucket.org Port 443 もしプロキシを使っ
会社の PC を使っていると、普段は会社用の GitHub アカウントで作業をするが ちょっとしたコードなどをたまに個人の GitHub リポジトリに保存したい時があり、その時はコミットも個人のアカウントで行いたい。 そういった感じで1台の PC で複数の GitHub アカウントを切り替えて使うための設定手順。 SSH を使った方法はググると記事がいくつか見つかるんだけど https の方はなかったのでメモ。 前提として、メインで使うアカウントについては すでにSSH鍵の登録や git config --global でユーザー名、メールアドレスなどの設定が済んでいるものとします。 TL;DR SSH の場合 サブアカウント用のSSH鍵を生成し、GitHub に登録する ~/.ssh/config を編集し、サブアカウント用の Host 情報を定義する 以下、各リポジトリで git@[サ
はじめに 1台のPCで複数のGitHubアカウントを使い分けたくなるシーンがたびたびあります。 たとえば会社のPCを使っている時に、自分のプライベートなリポジトリにちょっとしたコードをコミットするときなど。 そのような、「1台のPCで複数のGitHubアカウントを使い分ける」方法について、SSHを使った方法は調べると多くの方々の記事が出てきます。 【メモ】githubの複数アカウントにSSH接続するための設定手順 同一端末で、複数のGitHubアカウントを使い分ける方法 GitHubで複数のアカウントを使う場合のSSHの設定 が、httpsを使った方法はあまりweb上に情報が無いような気がします。 両方試してみたところhttpsの方がお手軽な感じがしたので せっかくなので2つの設定方法をメモしておきます。 ※ 元々は自身のブログにも投稿していた内容なんですが、どちらがオススメなのか皆さんか
サイトを見ようとアクセスしたら「このWebサイトのセキュリティ証明書に問題があります」というエラーが表示されること、たまにありますよね。 このセキュリティ証明書とはなにか?また、この警告の意味や出さないようにする方法はどうすればよいのか、解説していきます。なお、パソコンとスマホどちらで表示されても意味と対処は同じです。 セキュリティ証明書とは?人間でいう身分証明書と同様に「この接続先サーバーは安全である」ということを示し、「このサイト内での通信内容は暗号化される」と証明するものです。「SSLサーバ証明書」ともいいます。 暗号化されていないサイトで情報のやり取りをおこなうと、その情報をハッカーなど知識のある人物であればカンタンに傍受できてしまいます。 たとえば通販サイトでは、住所・氏名をはじめとする個人情報や、クレジットカードなどの重要な情報をやり取りするので、セキュリティ証明書を発行してい
今年はGoogle I/Oに初めて社員ではない立場で参加しました。全体の感想は Google I/O 2016まとめ(Web的視点) で公開していますが、今回はその中で、気に入ったセッションの1つである"Mythbusting HTTPS: Squashing security’s urban legends"について書いてみたいと思います。 セッションは大変良くまとまっていますので、YouTubeにあがっている動画を見れる人は動画を見て貰えれば良いのですが、時間が無いという人のために、その内容をまとめました。基本的には文字起こしに近いものです。 重要だとわかっているけど、なかなか導入に踏み切れない人も多いHTTPS。これについて、最新の状況が理解できるコンテンツとしてお役に立てるならば嬉しいです。 TL;DR HTTPSはPWAppなどWebにとって必須。 しかし、パフォーマンス悪化する
HTTPS is a secure protocol for the internet. Unlike the communication in HTTP, which happens in plain-text, the data transferred between the server and the client with HTTPS is encrypted. HTTPS also verifies the identity of the website we are accessing with a SSL/TLS certificate. It was initially used in online payment website, but in the recent age of privacy, it is deemed mandatory. That’s where
弊社の新規事業でWebサービスを作っていて、セキュリティトレンドの常時SSLってやつをやってみようと思った。 世のWebサービスを見てみるとやっている所が何故かほとんどなく、mixiやニコニコなどの大手もやってないようだ。ニコニコのURLを試しにhttpsにしてみたら繋がらず、mixiはhttpにリダイレクトされる。 うちは新規だから最初からhttps化することで特にデメリットはないと判断、安いSSL証明書を買ってhttpをhttpsにリダイレクトするようにした。技術的な難所はまったくないので問題なく実装完了し、これで安心度がちょっと上がったと思っていたのだが…。 つづく。 続き。 弊サービスではユーザーがYouTubeなどの動画を貼り付ける機能が重要なのだが、テストしてみるとニコニコ動画の埋め込みが動作しなくなっていた。調べてみるとニコ動の埋め込みコードがhttpなせいで、さらに最近のブ
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く