[prev in list] [next in list] [prev in thread] [next in thread]
List: wireshark-bugs
Subject: [Wireshark-bugs] [Bug 11567] Resolve hostname from DNS/Packet and or TLS Certificate
From: bugzilla-daemon () wireshark ! org
Date: 2019-03-30 16:45:34
Message-ID: bug-11567-15-dtG01VbK5w () https ! bugs ! wireshark ! org/bugzilla/
[Download RAW message or body]
--15539643340.870c9.13708
Date: Sat, 30 Mar 2019 16:45:34 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.wireshark.org/bugzilla/
Auto-Submitted: auto-generated
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11567
--- Comment #2 from LiquidMe <blue-t@web.de> ---
Wrong names on the outer side of the connection can happen and have been used
in the part to help tor bypassing restrictions via domain fronting, but the
benefit outweighs the problem of wrong data.
Maybe you can make it an option to display all of the found names to help the
user to evaluate the reliability of each of the layers.
Maybe mark them in color based on the reliability of the info.
If we can look inside the connection because we have the necessary session
keys, it is more trusworthy than what the higher layers tell you.
In times of TLS 1.3 where the SNI can be encrypted, we should also cover this
additional layer that might need to get unwrapped.
--
You are receiving this mail because:
You are watching all bug changes.
--15539643340.870c9.13708
Date: Sat, 30 Mar 2019 16:45:34 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugs.wireshark.org/bugzilla/
Auto-Submitted: auto-generated
<html>
<head>
<base href="https://bugs.wireshark.org/bugzilla/" />
<style>
body, th, td {
font-size: 12px;
font-family: Arial, Helvetica, sans-serif; }
p, pre { margin-top: 1em; }
pre {
font-family: Bitstream Vera Sans Mono, Consolas, Lucida Console, \
monospace; white-space: pre-wrap;
}
table { border: 0; border-spacing: 0; border-collapse: collapse; }
th, td {
padding: 0.25em;
padding-left: 0.5em;
padding-right: 0.5em;
}
th { background: rgb(240, 240, 240); }
th.th_top { border-bottom: 1px solid rgb(116, 126, 147); }
th.th_left { border-right: 1px solid rgb(116, 126, 147); }
td.removed { background-color: #ffcccc; }
td.added { background-color: #e4ffc7; }
</style>
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - Resolve hostname from DNS/Packet and or TLS Certificate"
href="https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11567#c2">Comment # \
2</a> on <a class="bz_bug_link
bz_status_CONFIRMED "
title="CONFIRMED - Resolve hostname from DNS/Packet and or TLS Certificate"
href="https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11567">bug 11567</a>
from <span class="vcard"><a class="email" \
href="mailto:blue-t@web.de" title="LiquidMe <blue-t@web.de>"> <span \
class="fn">LiquidMe</span></a> </span></b>
<pre>Wrong names on the outer side of the connection can happen and have been \
used in the part to help tor bypassing restrictions via domain fronting, but the
benefit outweighs the problem of wrong data.
Maybe you can make it an option to display all of the found names to help the
user to evaluate the reliability of each of the layers.
Maybe mark them in color based on the reliability of the info.
If we can look inside the connection because we have the necessary session
keys, it is more trusworthy than what the higher layers tell you.
In times of TLS 1.3 where the SNI can be encrypted, we should also cover this
additional layer that might need to get unwrapped.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>
--15539643340.870c9.13708--
[Attachment #3 (text/plain)]
___________________________________________________________________________
Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
mailto:wireshark-bugs-request@wireshark.org?subject=unsubscribe
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic