タグ

関連タグで絞り込む (18)

タグの絞り込みを解除

rfcに関するktakeda47のブックマーク (14)

  • HTTPステータスコード451(政治的な検閲)が正式に承認される


    mnot’s blog: Why 451? draft-ietf-httpbis-legally-restricted-status-04 HTTPステータスコード451がIETFで正式に承認された。近いうちにRFCとしても発行される。 元ネタは、Ray BradburyのFahrenheit 451(華氏451)というタイトルの小説で、これはディストピアな検閲社会を描いている。 451の意味は、403(禁止/権限がない)と似ているが、正確な意味は、ドラフトを引用すると、以下の通り。 このドキュメントはサーバーオペレーターが、あるリソース、あるいはあるリソースを含むリソース群に対し、閲覧を検閲するよう法的な命令を受け取った時に使うHypertext Transfer Protocol(HTTP)ステータスコードを規定するものである。 このステータスコードは、法律や一般大衆の雰囲気がサーバー
    ktakeda47
    ktakeda47 2015/12/21
    "抑圧的な国家は、検閲されている事実をも検閲するため、451を返すこと自体が検閲されるだろう。"
    リンク

  • 2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録


    このブログを読んでいる人なら Google や AWS の2段階認証︵マルチファクタ認証︶を有効にしていると思います。もしパスワードが漏れてしまってもワンタイムパスワードを入力しないと認証されないので安心です。 有名どころのサービスでは使えるところが増えてきましたが、2段階認証を有効にしていれば万全なのでしょうか。エンジニアである以上、その仕組みを理解したうえで自信を持って安全と言いたいところ。 というわけで、2段階認証は本当に安全なのか仕様を紐解きながら調べてみました。 ワンタイムパスワードの仕様 ワンタイムパスワードを生成する仕様は HOTP と TOTP の2つがあり、RFC の仕様になっています︵TOTP はドラフト段階︶。 HOTP (HMAC-Based One-Time Password Algorithm) TOTP (Time-Based One-Time P
    2 段階認証は本当に安全なのか調べてみた | はったりエンジニアの備忘録

  • Google『gmailアドレスが日本語対応するよ！！』→エンジニアが阿鼻叫喚

    リンク GIGAZINE Gmailでメールアドレスに日本語など非アルファベット文字の利用がOKに Googleは本日、Gmailのアドレスとして日本語を含む非アルファベット文字を対応させると発表しました。Official Google Blog: A first step toward m C4 @c4_user WEB)やめてぇええええ！！！どうやってバリデートチェックすればいいの！！　Gmailでメールアドレスに日本語など非アルファベット文字の利用がOKに - GIGAZINE gigazine.net/news/20140806-… 2014-08-06 14:02:14

    Google『gmailアドレスが日本語対応するよ！！』→エンジニアが阿鼻叫喚

  • XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス


    メールアドレスの﹁ルール﹂に関する話題が盛り上がっていますね。 ﹁メールアドレスのルール﹂系まとめがそろって間違ってるのでご注意を ﹁メールアドレスのルール﹂なんて使ってはいけない3つの理由 これらのエントリに異論があるわけでありません。メールアドレスに関するルールというとRFC5322などがあるものの、現実の運用では簡易的な仕様を用いている場合が大半である…という事情は、私も以前ブログに書きました。、 本稿では、﹁空前のメールアドレスのルールブーム(?)﹂に便乗する形で、RFC5322に準拠したメールアドレスで、XSSやSQLインジェクションの攻撃ができることを紹介します。と言っても、SQLインジェクションについては、過去に書きましたので、本稿では、RFC5322バリッドなメールアドレスでSQLインジェクションとXSSの両方ができるメールアドレスを紹介します。 まず、攻撃対象として、以下
    XSSとSQLインジェクションの両方が可能なRFC5322適合のメールアドレス

  • Pretty RFC

    The RFC is now diamonds RFCs are documents produced by The Internet Engineering Task Force, and many are official standards for various Internet protocols. This site indexes and formats these documents for easier finding & viewing. Note: most RFCs can't be prettified at the moment, as their source files are unavailable to the public and need to be requested from rfc-editor.org. I'm working on this

    ktakeda47
    ktakeda47 2012/05/17
    "Pretty RFC"
    リンク

  • ke-tai.org > Blog Archive > auのメールアドレスの仕様を変更、ようやくRFC準拠となったようです

    auのメールアドレスの仕様を変更、ようやくRFC準拠となったようです Tweet 2009/9/25 金曜日 matsui Posted in au, ニュース | No Comments » ezweb.ne.jpで取得できるメールアドレスの仕様が変更になったようです。 「..（連続するドット）」、「@の前の.（ドット）」などが禁止されたようです。 →　Web屋のネタ帳　au by KDDIがメールアドレスの設定仕様を再変更。2006年の改悪前に戻しましたの巻 [neta.ywcafe.net] →　au by KDDI　Eメールアドレス変更方法 | 迷惑Eメール防止方法 [au.kddi.com] ケータイのメールアドレスは各社ともRFC無視で進められてきたため、連続するドットや@前のドットなどを使うことができ、一部MTAから送信できないなどの問題が起こることがありました。 2009年

    ktakeda47
    ktakeda47 2009/09/26
    「これで全キャリアが一応RFC準拠となったわけですが、あくまで新規取得分だけ・・・」。はぁ～・・・
    リンク

  • RFC 2550 - Y10K and Beyond (日本語訳)

    この文書は 1999 年のエイプリル・フールに公開された RFC2550 を和訳したものです。 訳者は翻訳に関し何らの保証もいたしません。 S. Glassman M. Manasse J. Mogul Compaq Computer Corporation 1 April 1999 Network Working Group Request for Comments: 2550 Category: Stinkards Track(1) (Y10K とその先) このメモの位置づけ このメモはインターネット・コミュニティーのために情報を提供するものである。 このメモはいかなるインターネット標準も定めない。 このメモの配布に制限はない。 著作権表示 Copyright (C) The Internet Society (1999). All Rights Reserved. 要旨 千年紀の終わ

  • Implementation of RFC2322

    作成: 2000年11月27日 更新: 2001年4月13日 このページについて このページでは、日本ではまだほとんどその実装例が公開されていない RFC2322 (洗濯バサミ DHCP による IP ナンバーの管理) の実装例を 公開します。厳密に RFC2322 に従うのは少々困難な部分もあるため、 一部で独自仕様を実装しました。 洗濯バサミDHCPとは 今回の実装について 必須デバイス 実際の運用手順 問題点 リンク HyperRFC ソニー提供の RFC 検索サイト 森さん による RFC2322 の邦訳。 RFC2322サーバ 私以外にも導入した人がいるようです。 このページは「となりのらすかる」氏の協力を得て作成しました。 この場を借りてお礼申し上げます。 また、洗濯バサミによる IP 管理のアイデアを創造した Daniel Ockeloen 氏、 および 1998年4月1日に

  • 槻ノ木隆の「BBっとWORDS」

    ■ RFCって何？ 1月初旬、SSHに関するRFCが公開されました。RFC4250からRFC4256までの7つがそれなのですが、個人的には「え？　RFCじゃなかったの？」ということにむしろ驚いたりもしました。そこで思いついたのが、「そういえば、そもそもRFC自体の説明をしていなかったなぁ」ということ。そんなわけで、今回はRFCを取り上げてみたいと思います。 RFCは「Request For Comment」の略で、直訳すれば「コメント募集」なわけですが、日本語では「標準勧告文章」と訳されるのが一般的です。文字通り、インターネットに関わるさまざまなプロトコルや技術的手段、情報などを網羅するものであり、事実上インターネットを規律する唯一の根拠と言っても良いでしょう。もっとも、インターネットはRFCを拠り所に運営されているわけで、その意味では規範と言っても良いわけですが、実際のRFCはもう少しく

  • セキュリティ関連 RFC：IPA 独立行政法人 情報処理推進機構

    IPA/ISEC（独立行政法人 情報処理推進機構 セキュリティセンター）は、インターネットセキュリティに関する重要な RFC（Request for Comments）を日本語に翻訳して提供しています。 RFC は、IETF (Internet Engineering Task Force) におけるインターネットコミュニティの標準等の検討が公表される一連の文書であり、1969年に発行され始めました。それらの内容としては、インターネット標準の仕様のみならず、現時点における最善の実践（BCP）、FYI（For Your Information）を含む情報提供、実験的なもの、および、歴史的なものがあり、広範にわたります。原文は、英語で記述されています。 この目的は、 「ベンダーによるインターネットセキュリティ機能の実装を促進すること」および「ユーザのインターネットセキュリティについての認識を向

  • IETFとRFC - JPNIC


    IETFとは インターネット技術の国際標準を議論策定しているIETFは、 コンピュータサイエンスの技術者達が、 自身の実験網を構築運用するために共通の技術仕様を策定および共有するために草の根的な議論を行うグループから発展したものです。 当初、10名以下のグループからスタートしたグループは、2000年当時でも、 年3回のIETF会合に2000名以上の参加者があり、24時間絶え間なく電子メールによる議論が行われていました。IETFにおける標準化のプロセスは、 ITU-TやISOにおける標準化のプロセスとは大きく異なっています。 ここでは、IETFの概要、歴史、組織構造、標準化のプロセス、 およびIETFの文化についての解説を行います。IETFとは～はじめに～IETFの背景と歴史IETFの組織構造IETFにおける標準化プロセスIETF会合の様相IETFとは～むすび～IETF会議

  • » RFC Editor

    The RFC Series The RFC Series (ISSN 2070-1721) contains technical and organizational documents about the Internet, including the specifications and policy documents produced by five streams: the Internet Engineering Task Force (IETF), the Internet Research Task Force (IRTF), the Internet Architecture Board (IAB), Independent Submissions, and Editorial. Browse the RFC Index HTML (ascending) • HTML

  • ＲＦＣ日本語版リスト


    リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳︵和訳︶のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて1行にしています。 ︵高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています︶ 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります︵場所が変わって見つかっていないだけかもしれません︶。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開

  • RFC

    拡張されたメールシステムステータスコード 簡単な解説 RFC 3030 大きなバイナリのMIMEメッセージを送信するためのSMTPサービスの拡張 この文書はSMTP(単純なメール転送プロトコル)サービスに2つの拡張を定義す る。最初の拡張により、DATAコマンドの代わりに、効果的に大きな MIME(Multipurpose Internet MailExtensions)メッセージを送るための"BDAT" と呼ばれるものを利用することをSMTPクライアントとサーバが取り決めること ができる。2つ目の拡張では、バイナリ送信エンコーディングを用いるMIMEメッ セージ送信が取り決められるようになり、BDATコマンドに優位性を与える。こ の文書はRFC 1830の更新と無効化を意図する。 RFC 3251 Electricity over IP この文書は、IP上で送電するためのアーキテクチャで

  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.