アカウント名:
パスワード:
まずはこれ: Not All RFCs are Standards [ietf.org] そしてこれ: The Internet Standards Process [ietf.org]
さて、
Moore タンに同意…。
がどうして
# 何で RFC よみたいな。
になるのだ? Keith タンを始めとする連中は 「Standards Track にするのはどうかと」 という点で議論していると思うのだが。 実際、 「(No [ietf.org]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
反対じゃ (スコア:0)
つか、こんなのが普及しちゃうと、またフィルタ用のミドルか何かで金がかかると…。
マジで勘弁。
# つーか、こんなのアングラツールで良いだろみたいな。
# 何で RFC よみたいな。
Re:反対じゃ (スコア:1, 参考になる)
Re:反対じゃ (スコア:1)
over HTTPSでやられた日にゃ…
#企業とかのproxyではHTTPSが全面禁止になったり
Re:反対じゃ (スコア:1)
偽証明書を返す https プロキシとか導入するのかな。
実はサーバ～プロキシ間のSSLとプロキシ～クライアント間で
別々のセッションを張っているとか。
証明書/鍵はプロキシが偽造し、そのCAは自社専用。
証明書の妥当性チェックはクライアントでなくてプロキシがやってくれる。
# mishimaは本田透先生を熱烈に応援しています
Re:反対じゃ (スコア:0)
接続できなきゃ何もできませんから
認証機能がPORT単位で付いているProxyなら単純に認証DB/許容IPを分ければ良いだけです
使えなくするんだからこれで十分
無論全員が使うためにHTTPSも
Re:反対じゃ (スコア:0)
と言うかhttpsが業務で必要になる事は特定の人以外稀なのでそうなったら許可制でしょうね
1.http/https共に不許可
2.httpのみ許可
3.http/httpsを許可
の3種類に増えるだけかと
無論httpレベルではトンネル系の処理をされないように解析&遮断が必要になると.
実は (スコア:0)
Re:反対じゃ (スコア:0)
クライアント作る側は
常に疑ってかからないとセキュリティホールになる。
MIMEリストつくるのも馬鹿馬鹿しくなってるし、
もう無くなってくんないかな。。
それは MIME の問題？ (スコア:1)
RFC（や他の標準化規格）にすべきでないっていう意味？
# mishimaは本田透先生を熱烈に応援しています
Re:それは MIME の問題？ (スコア:0)
そうではなくて、過去を参考にもっと有効な方法を模索しましょうって話。
#MIMEはOSなどに任せたいです。
Re:反対じゃ (スコア:0)
それこそフィルタしやすくするためでは？
httptunnelみたいな、独自形式の実装がたくさん増えるより、
RFCで定められた規格のツールが普及した方が、フィルタしや
すいと思いますが。
# まぁ、フィルタしやすいようじゃ普及しないかもしれません
# が。（ぉ
Re:反対じゃ (スコア:0)
Re:反対じゃ (スコア:0)
まずはこれ: Not All RFCs are Standards [ietf.org]
そしてこれ: The Internet Standards Process [ietf.org]
さて、
がどうして
になるのだ?
Keith タンを始めとする連中は 「Standards Track にするのはどうかと」
という点で議論していると思うのだが。
実際、 「(No [ietf.org]
Re:反対じゃ (スコア:0)
"つーか"と書きましたが、"つーかそれ以前に"位にとって貰えれば。