<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="">Hi,</span><div class=""><span class=""><br class=""></span></div><div class=""><span class="">RFC 8882, DNS-Based Service Discovery (DNS-SD) Privacy and Security Requirements, was issued today and is relevant to this discussion.</span><div class=""><span class=""><br class=""></span></div><div class=""><a href="https://www.rfc-editor.org/info/rfc8882" class="">https://www.rfc-editor.org/info/rfc8882</a><span class=""><br class=""></span><span class=""><br class="">-- Nick Briggs<br class=""></span><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Date: Wed, 09 Sep 2020 14:01:06 +0200<br class="">From: Hugo Beauzée-Luyssen <<a href="mailto:hugo@beauzee.fr" class="">hugo@beauzee.fr</a>><br class="">To: "Mailing list for VLC media player developers"<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><<a href="mailto:vlc-devel@videolan.org" class="">vlc-devel@videolan.org</a>><br class="">Subject: Re: [vlc-devel] [PATCH 9/9] lua: http: Announce the web<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>interface over mdns<br class="">Message-ID: <<a href="mailto:32ce7ad3-cf39-436e-8f51-094ebc24cb06@www.fastmail.com" class="">32ce7ad3-cf39-436e-8f51-094ebc24cb06@www.fastmail.com</a>><br class="">Content-Type: text/plain;charset=utf-8<br class=""><br class="">On Tue, Sep 8, 2020, at 4:51 PM, Rémi Denis-Courmont wrote:<br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Hi,<br class=""><br class="">Le tiistaina 8. syyskuuta 2020, 15.10.40 EEST Hugo Beauzée-Luyssen a écrit :<br class=""><blockquote type="cite" class="">I agree there is much to do with regard to the web interface, and/or a new<br class="">remote control interface. However, I doubt that this is something we can<br class="">address, at least in its entirety, for VLC 4.<br class=""></blockquote><br class="">I don't think there is that much to do there. If we keep the existing HTTP <br class="">application layer and TLS, it's mostly about generating a key pair <br class="">automatically by calling some GnuTLS function (or spawning a child process).<br class=""><br class="">Generating a token is not exactly hard or time-consuming, nor is linking a QR <br class="">code.<br class=""><br class="">But that's not even very relevant. The question is not how much work there is. <br class="">The question is if it's reasonable to expose the interface before it is <br class="">secured.<br class=""><br class=""><blockquote type="cite" class="">As Pierre noted, this set is aimed at simplifying pairing with a VLC remote,<br class="">hence the focus on announcing the HTTP interface. The core part is likely<br class="">to help us advertise future services though so it's ultimately not only for<br class="">remotes.<br class=""></blockquote><br class="">I think everybody agrees there. Advertising the web interface would be <br class="">completely pointless as browsers wouldn't pick the advertisement.<br class=""><br class=""><blockquote type="cite" class="">With regards to the security implications of announcing the web interface,<br class="">given that someone is looking to perform malicious operations using the<br class="">HTTP interface, I don't see the difference between an explicit MDNS<br class="">announce and a quick port scan, beside maybe costing the attacked a few<br class="">seconds.<br class=""></blockquote><br class="">I have to disagree for 3.5 reasons.<br class=""><br class="">1) Port scanning might be viable on a large campus to find some always-on VLC. <br class="">Hopefully a strong enough password, and a decent network security policy <br class="">prevents breaking in. Advertising is telling everything on the local network <br class="">that you're there now. Any cheap stupid hacked IOT gadget or CPE can pick it <br class="">up and MITM, as can somebody else on a public WiFi.<br class=""><br class="">There is definitely some overlap with port scanning, but it looks like orders <br class="">of magnitude worse exposure. It's also more visible and thus more prone to <br class="">hostile PR.<br class=""><br class=""><br class="">2a) The advertising in itself actually adds a MITM risk, as the remote <br class="">applications have no means to distinguish the legitimate announces from <br class="">attacker's. Currently at least the user has to verify the IP address. So it's <br class="">not just adding exposure to the existing insecure interface, it's actually <br class="">making the sethings even more insecure.<br class=""><br class=""></blockquote><br class="">I don't understand the concept of MITM when announcing an identify. I get that an attacker could try and impersonate a running VLC but then you end up with 2 VLCs with a different IP, and that should instruct anyone to check why there are 2, and which one to connect to, if not giving up before finding out why there are duplicated records.<br class=""><br class=""><blockquote type="cite" class="">2b) It's not even clear that the proposed API (patch 1) can sustain the <br class="">hypothetical secure control interface. In fact, it looks very much like it <br class="">can't, as there are no ways to tie the announce to any kind of identity.<br class=""><br class=""></blockquote><br class="">I'm not sure to understand that point, you have the service name, type, additional TXTs, and IP/hostname. That's as far as MDNS goes (AFAIK)<br class=""><br class=""><blockquote type="cite" class=""><br class="">3) There is no sunset strategy for advertising the non-secure interface. If we <br class="">cannot even agree to remove an obscure user-hostile feature that literally <br class="">never worked like VLM schedules, how are we ever going to remove this user <br class="">friendliness feature if it gets merged?<br class=""><br class=""></blockquote><br class="">Discussing until reaching consensus, I suppose, but why would we need a sunset strategy for something that isn't merged when the issue appears to be an already merged feature.<br class=""><br class="">I feels to me like this is something the users should be warned about, and could advertise at their own risks, but IMO the risk is rather low in most environment<br class=""><br class="">-- <br class=""> Hugo Beauzée-Luyssen<br class=""> <a href="mailto:hugo@beauzee.fr" class="">hugo@beauzee.fr</a><br class=""></div></div></blockquote></div><br class=""></div></div></body></html>