タグ

HTTPとhttpに関するdefiantのブックマーク (59)

  • 自堕落な技術者の日記 : HPKP(HTTP Public Key Pinning)公開鍵ピニングについて考える - livedoor Blog(ブログ)

    もくじ 1. はじめに 2. HPKPが生まれた背景 3. HPKPの仕組み 4. ピンの設定の考察 4.1. ピンの値の取得方法 4.2. 証明書チェーンに一致するピンの選択 4.3. 証明書更新とHPKPヘッダの設定変更の運用方法 4.4. バックアップピンという名前のイケてなさ 4.5. CA鍵のバックアップピンのオススメの値 4.6. 証明書チェーン中で複数ピンをつけても意味はない 4.7. 同じCA証明書にPinし続ける場合の課題 4.8. 2つのCA証明書にPinする場合の課題 4.9. max-ageのオススメ値を考える 5. HPKPはどの程度使われているのか 6. 今のHPKPの何がいけなかったのか 7. おわりに 8. (参考) HPKP関連の勉強になるリンク 9. 追記 9.1. 追記(2017.02.26) HPKPのブラウザサポート状況 9.2. 追記(2017.

  • ISUCON6予選をC++で参加して予選通過した話

    チーム名「Anago」で @iwiwi, @zuisou, @imos の 3 人で ISUCON6 予選に参加し,幸運にも 1 日目 3 位で通過することができました.@iwiwi が「ISUCON に C++ で参加したい!」と言っており,それを全力バックアップをしようと思ったのがきっかけの参加でした. 前日までにやったこと C++ で全てを書けば最速になるのは自明なのですが,C++ は参考実装として与えられていないだけではなく,HTTP サーバを書くことを想定していない言語のため準備には苦労しました. C++ で HTTP サーバを書く方法は,既存の Web サーバ (e.g., nginx, Apache, H2O) のプラグインを書いて実装するか,FastCGI として実装するか,フルスクラッチで書くかの選択肢が考えられますが,プロセス間通信を避けて爆速にしたかったので,事前に

  • Google、HTTPページに警告表示 まずはパスワード入力から

    WebサイトのHTTPS接続を推進している米Googleは9月8日、パスワードやクレジットカード番号を入力させるWebページに通信の内容が暗号化されないHTTP接続が使われている場合、2017年1月から安全でないページとみなすと発表した。長期的には全てのHTTPページを安全でないページとして扱う方針。 発表によると、2017年1月にリリース予定のWebブラウザ「Chrome 56」から、パスワードなどを入力させるWebページにHTTPが使われている場合はアドレスバーのURLの前に灰色で「Not secure」の文字を表示する。 Googleは、WebサイトがHTTPSを使っているWebサイトを検索で優先するなど、HTTPからHTTPSへの移行を促す措置を講じてきた。HTTPSの実装にかかるコストなどの負担も軽減されつつあり、デスクトップ版のChromeで読み込まれるWebページのうち、HT

    Google、HTTPページに警告表示 まずはパスワード入力から
  • HSTS (HTTP Strict Transport Security) の導入 - Qiita

    HTTPで接続した際に、強制的にHTTPSへリダイレクトし、以降のそのドメインへの接続はすべてHTTPSとする機能がHSTS (HTTP Strict Transport Security) である。RFC6797で標準化されている。 これはHTTPヘッダに以下を含むことで実現される。 Strict-Transport-Security:max-age=有効期間秒数;includeSubDomains max-ageではHTTPSで通信する期間を設定する。また、includeSubDomainsを指定することで、サブドメインにもHSTSが適用されるように設定できる。 HSTSのサポートは、2015年6月9日にマイクロソフトがIEへのサポートを追加したことで、すべてのメジャーブラウザにおいてサポートが完了し、HTTPサーバーとしてもApacheを始めとし設定が可能だ。 Apacheの設定 A

    HSTS (HTTP Strict Transport Security) の導入 - Qiita
  • セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita

    最近はハンドリングしくてもいいや的な、入力改ざんで発生するバリデーションエラーをそのまま500のHTTPステータスで返すと、攻撃者が「なんか攻撃成功しちゃいそう」って思っちゃうとかなんとかで、監査的なところから「500はやめろ」って言われることがあります。 一理ある ということで、安易に500を返さない方法を考えてみます。 HTTPステータスコードにあまり馴染みのない方は、こちら…ではなく、こちらをまず読んでください。 HTTPステータスコードの使い分け基礎 400 まず、ユーザの入力値、データの状態によってエラーになるケースは 400 Bad Request とします。エラーメッセージを表示して再入力を促すHTMLページを返す、一般的な入力エラー系の遷移は200 OKを返しても、実用上問題はないかと思います。 ユーザの操作が原因で、サーバ処理がエラーになった場合も400で扱うのはおかしい

    セキュリティ監査で文句を言われないHTTPステータスコードの使い分け - Qiita
    defiant
    defiant 2016/08/15
  • Webの技術トレンドを自動解析するサイト「HTTP Archive」

    GoogleのSteve Souders氏は3月30日(米国時間)、主要Webサイトのコンテンツを自動分析してレポートする新しいサービス「HTTP Archive」を開始したことを発表した。 HTTP ArchiveAlexa、Fortune 500、Quantcastなどのいくつかのデータをベースに主要トップサイト約17,000を選出し、コンテンツの分析結果を報告するサービス。HTTP ArchiveのプログラムそのものはOSSのもとで公開され、分析後のデータもダウンロードできる。 HTTP Archiveに掲載されているデータは2010年10月から収集されたものと説明があり、今後2週間おきにアップデートするとされている。実際のWebページでどういったコンテンツが使われているか知ることは、高速に動作するWebアプリケーションやサーバシステムを開発する上で有益なデータとして活用できる。

  • 日本のEコマースサイト売上上位300社の内、268サイトの品質調査結果

    Webサイトの品質調査・改善サービスを提供している株式会社Spelldata(店:東京都千代田区、代表取締役: 竹洞 陽一郎)は、2016年1月4日から1月22日の期間、日の売上上位300社のEコマースサイトの内、自社サイトを持つ285社のWebサイトの品質の調査を行いましたので、調査結果をお知らせいたします。 ■調査結果 重いページあたりの容量…平均3.6MB 大量の外部接続…平均28ホスト 大量のネットワーク接続数…平均62接続 画像やJavaScriptCSSが大量に利用されている…平均226ファイル HTMLのエラーが多い…平均145エラー トップページの容量 トップページを構成するコンテンツ配信先の接続ホスト数 トップページのTCPIPコネクション数 トップページを構成する画像、CSSJavaScriptなどのオブジェクト数 トップページのHTML文法エラー数 詳細資料は

    日本のEコマースサイト売上上位300社の内、268サイトの品質調査結果
  • HTTP Archive: State of the Web

    Report: State of the Web This report captures a long view of the web, including the adoption of techniques for efficient network utilization and usage of web standards like HTTPS.

    HTTP Archive: State of the Web
  • なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと

    先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。

  • [メモ] TCP上(もしくはHTTP)にリトライ可能なアプリケーションプロトコルを実現する方法

    HTTP/1.1の持続的接続においては、サーバがリクエストを受け取ったあとに異常終了したのか、リクエストを受け取らずに接続を閉じたのか判別することができない。このため、べき等性の保証がないアプリケーションにおいて、リトライを行うべきか否か自動的に判断できなくなる場合がしばしば発生する注。 リトライ可能か否か(ピアがメッセージの処理を開始した否か)を判別するには、より細かな情報交換を行う別種のプロトコルを採用しても良いが、複雑なプトロコルはパフォーマンスに悪影響を及ぼす可能性が高いので避けたいところである。 というわけで、以下題。 pipeliningを行わないHTTP/1.1のような単純なリクエスト/レスポンス型プロトコルをそのままに、アプリケーションレイヤへのリクエスト到達可否を判定する手軽な方法としては、SO_LINGERを用いる方法がある。具体的には、以下のような形式でサーバを実装

  • セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ

    GMOサイバーセキュリティ byイエラエ株式会社は国内トップクラスのホワイトハッカーが多数在籍するサイバーセキュリティの会社です。攻撃手法に関する豊富な知識と最先端の技術を持つホワイトハッカーが仮想敵となり、お客様の抱えるセキュリティ上の問題の可視化と課題解決をサポートします。 「誰もが犠牲にならない社会を創る」をミッションとして掲げ、デジタルネイティブの時代を生きるすべての人が安全に暮らせるインターネット社会創りに貢献します。

    セキュリティ診断・検査のGMOサイバーセキュリティ byイエラエ
    defiant
    defiant 2014/02/25
  • GmailがハマったSPDYの落とし穴 - ぼちぼち日記

    1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY&WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図1:2012年のハイプサイクル: 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo

    GmailがハマったSPDYの落とし穴 - ぼちぼち日記
  • 実はそんなに怖くないTRACEメソッド

    Cross-Site Tracing(XST)という化石のような攻撃手法があります。「化石」と書いたように、既に現実的な危険性はないのですが、XSTに関連して「TRACEメソッドは危険」というコメントを今でも見ることがあります。 このエントリでは、XSTという攻撃手法について説明し、XSTおよびTRACEメソッドについてどう考えればよいかを紹介します。 TRACEメソッドとは HTTP 1.1(RFC2616)では、8種類のメソッドが定義されています。GET、POST、HEADなどはおなじみのものですが、それ以外にPUT、DELETE、OPTIONS、TRACE、CONNECTの5種があります。 このうち、TRACEメソッドは、HTTPリクエストを「オウム返しに」HTTPレスポンスとして返すもので、以下のようにGET等の代わりにTRACEとしてWebサーバーにリクエストします。 TRACE

    実はそんなに怖くないTRACEメソッド
  • 【HTTP2.0最新動向】第2回:HTTP/1.1からのアップグレードメカニズム 11月に開催されたIETF85のhttpbisワーキング・グループから

    defiant
    defiant 2012/12/14
  • 【HTTP2.0最新動向】第1回:HTTP/2.0の策定、ついに始まる 

    defiant
    defiant 2012/11/02
  • PATCH メソッド、新しい HTTP Status Code - 日向夏特殊応援部隊

    Spec はあまりミーハーに追いかけても後で痛い目にあったりするもんですが、久しぶりに面白いなーと思ったのでちょっと取り上げてみます。 ちなみに斜め読みなので記事の正確性についてはあまり保証しませんw PATCH Method for HTTP RFC 5789 にある PATCH Method for HTTP ですが、RESTful API の致命的な弱点でもある PUT がリソースの完全なる置き換えなのに対して、PATCH は差分適用である所が中々面白いです。 2.1. A Simple PATCH Example のサンプルを見てみます。 PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100

    PATCH メソッド、新しい HTTP Status Code - 日向夏特殊応援部隊
    defiant
    defiant 2012/02/15
  • httpstat.us

    This is a super simple service for generating different HTTP codes. It's useful for testing how your own scripts deal with varying responses. Just add the status code you want to the URL, like this: httpstat.us/200 We'll return a response like this: HTTP/1.1 {status code} {status description} Content-Type: text/plain or application/json Content-Length: {something} {any custom response headers} {st

  • 1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記

    最近のモダンなWebブラウザがサポートしている、セキュリティに関連しそうな X- なHTTPレスポンスヘッダをまとめてみました。それ以外にもあったら教えてください。 X-XSS-Protection 0:XSSフィルタを無効にする。 1:XSSフィルタを有効にする。 XSSフィルタを有効にすることでエンドユーザがXSSの被害にあう可能性が低減するが、まれに誤検知することで画面の表示が乱れることもある。IE8+、Safari、Chrome(多分) で有効。IEでは「X-XSS-Protection: 1; mode=block」という指定も可能。 2008/7/2 - IE8 Security Part IV: The XSS FilterBug 27312 – [XSSAuditor] Add support for header X-XSS-Protection X-Content-Ty

    1分でわかる「X-ナントカ」HTTPレスポンスヘッダ - 葉っぱ日記
  • しすろぐ : HAProxy (High Performance TCP/HTTP Load Balancer)

    よさげな Proxy & Load banalser。試してみようと早速 ports/net/haproxy を導入。お約束で /etc/rc.conf に haproxy_enable="YES" を追加して終了。設定ファイルを examples/haproxy.cfg から /usr/local/etc/haproxy.conf にコピーして適当にエディットしたが、起動せず。...と思ったら startup スクリプトがいまいちで haproxy_flags="-f /usr/local/etc/haproxy.conf -p /var/run/haproxy.pid" なんてのも追加しないとダメだった。ports の version が最新の 1.2.14 ではなくて 1.1.32 だからかな? バランスサイトの keep alive チェックに使う URL を設定できるのは面白

  • HAProxy - The Reliable, High Perf. TCP/HTTP Load Balancer

    Quick News Dec, 5th, 2023 : HAProxy 2.9.0 release This release has received a lot of small changes that are difficult to summarize. Most of them were aimed at improving performance and resource usage in general (zero-copy forwarding, QUIC's smaller footprint for closed connections, improved scalability), others focusing on better integration with other components (support for the AWS-LC crypto lib