暗号とかセキュリティについて詳しい人来て
■ このスレッドは過去ログ倉庫に格納されています
ある文章を作って
aからbに送る必要があって
使える鍵は固定の共通鍵のみ
再送攻撃(リプレイ攻撃、反射攻撃)防ぐにはどうしたら最も簡単?
いちいち鍵を作り直すsslとかが簡単なんだが鍵を作り直すのはなしで頼む
あと文章は伝えたいことがbにわかれば好きなように変えても良いしbの実装も自由
簡単かどうかで頼む >>2
それはなしで頼む
それにそれも再送攻撃できるだろ
コピーして送れば そもそも再送攻撃を想定するネットワークで固定鍵を使うのがナンセンスでは? >>4
aからbにcって内容を暗号化して送るじゃん?
そしたら攻撃者が暗号化されたcを盗聴してbに送りつけるような攻撃
例えばcの内容が商品を買いますって文章なら攻撃されると2回商品を買いますって内容が行くことになる >>5
もちろんそう思うけど
なんかやり方あるのかなと‥
俺が考えたのはカウントアップするような方法で
文章に適当な数字つけて送って
次送るときは数字+1ってして
そのカウントアップごとの数字が送られてこなかったらサーバが拒否するとかなら実装できそうかな?とか思った なんでそんなWikipediaに対策方法書いてあるようなことでスレたてるの? >>9
そもそもcの内容は「商品を買います」というような情報じゃない
a個人を特定する情報だから
再送攻撃によってbが第三者をaと勘違いして何らかの情報を送ることを期待してる攻撃だから
単に>6を防ぐだけなら二重送信を切ればいいだけ >>13
c本文にタイムスタンプでもつければいいじゃん
同時刻に二重送信することなんてないんだろ? >>16
ないけどサーバ側の実装どうする?
遅延考えるとタイムスタンプはサーバ側で受けた時間+x秒許さなきゃいけないけど
攻撃者がその場で再送攻撃出来るなら受け付けられる
>>17
なる
さっきもいったように商品買いますメール(発注メール)が2回いく
イタズラだけどな単純な 送信日時から生成するチェックディジットでどう
重複は削除するとして >>19
なるほどな
重複は削除か
確かにタイムスタンプまで全く同じなものは受け付けなくていいかもしれない >>18
>>16
ごめんこれ的外れだったな
猶予とか関係なかった タイムスタンプが一番それっぽいな
カウントアップにしようと思ったけどタイムスタンプにするわ
猶予は何秒にするかな >>18
ちげーよ
そもそもcのメッセージは同時刻に送付されるようなものなのか?
そうじゃないなら「同じタイムスタンプ」で送られたメッセージは偽物ってわかるじゃん >>23
ごめんありがとう
確かにタイムスタンプの重複見ればいいわサンクス
それが一番簡単かな >>22
猶予いらんって言っといてわかってないやん >>24
いやもうsslで暗号化されてるんだけど
盗聴されてるっぽくてな‥
だから簡易的なもので二重で暗号化する
盗聴してるっぽい人はガチな攻撃者じゃないしおそらく解読できない >>26
前のタイムスタンプから時間が経過してたら受け付けるようにするか そのタイムスタンプが1時間前のものだとしても
>>27
>>28
みたいなのが背景 ググったら「SSL/TLSの場合、各パケットにシーケンス番号が暗号化されて入ってますので、同じパケットを2回サーバに送ってもサーバが攻撃を検出できます。 」って書いてた >>30
それはssltlsレベルの話?tcpの話ではなく?
ssltlsはそもそも鍵が毎回変わるから
sslで暗号化された内容がわからないとそもそも再送攻撃は難しい 2回送信されてるからと言ってどちらもアプリケーション層まで到達してるわけではないだろ >>32
あーそれは古い過去のものもとっておくってことか >>34
ごめんどういうことだろ
完全にtcpのコネクションやらは攻撃者は一からはる >>33
ん?
現にsslにしてるって書いてたけどそれなのにリプレイ攻撃を心配してるの? >>37
sslは復号化されて中身は盗聴されてる前提だ
だから攻撃者はTCPハンドシェイクもsslハンドシェイクも両方やり直して再送攻撃できる >>39
しゃーない
むりやりsslの復号化を対策するために色々すると外部とそもそも通信できなくなる
だからSSLレベルの復号化自体は許可してアプリケーション層のデータは独自で暗号化することにした ありがちな通信が盗聴されてる訳じゃなくて
受け取ったbから漏れてるパターンでは >>45
ちがう‥
>>46
そういう製品が売ってるんだよ >>50
この記事に載ってるようなやつな
もちろん攻撃者はあらかじめ偽のルート証明書をインストールさせなきゃならない
https://milestone-of-se.nesuke.com/nw-basic/fw/utm/ うちでそういう製品が使われてて
中身見られてるから管理者に見られないように独自でアプリケーション層を暗号化したい
管理者に色々イタズラされたくないからスレタイみたいなこと聞いてる なるほど
そもそもSSLじゃないんだね
騙されたわー いや、SSLはインターネット側やん
おまえとハッカはSSLで保護された関係にないがな >>56
どういうことだ
aとbがsslコネクションはろうとしたときに
cが割り込んで偽の証明書をaに送りつけるだけでaはcとコネクションはっちゃうんだよ >>42
たんにSSLに流すCをもっかい暗号化すりゃいいだけじゃん >>61
そう!
それをやるだけ
その暗号化で簡単な方法って何があるかなと
そこまでガチじゃなくてよくて再送攻撃防げるだけで良い >>64
なるほどたしかにそれが簡単そうに思えてきた >>66
カウンタもいいよな
タイムスタンプより楽そうな気もする >>65
sslが盗聴されてる時点で意味がないがな わろた
GPGで良いんじゃないの
お互いの公開鍵を交換しておけば >>58
まさか第三者が復号できる証明書を信用してる前提とは思わんかったからさ
もうSSLとか言わんといてーや紛らわしいのう >>68
レスしてからそう思った
>>69
署名?か?
それ簡単か?
>>70
sslプロトコルには則ってるぞ んでリプレイ攻撃とかの話を無理矢理当てはめようとするとその丸見え回線の中に独自のSSLのトンネルを作るという話とも捉えられるがそうでもないんか >>72
まあそれもできるけど
大変そうかなって思っちゃった まーいいや
なんか話それてきたしそろそろやめます
みんなさんくす 適当なルールで検証用のハッシュ値つけるのが簡単だと思う
ハッシュ化する対象に期限のタイムスタンプも混ぜればよりよい
ライブラリでやるならjwtとかならめちゃくちゃ実装簡単 えぇ…そういう話でもないんか…
リプレイ攻撃とはなんだったのか… わろた
中身わかってて正規の手段で送るならリプレイ攻撃ではなくただの送信だわな笑 親とか言ってる時点でしょーもない
sshとかSSLとか言ってるけどわかってなさそう ■ このスレッドは過去ログ倉庫に格納されています