[mythtv-users] Open Failed: No suitable proxy found

Stephen Worthington stephen_agent at jsw.gen.nz
Sat Mar 3 00:39:36 UTC 2018

On Fri, 02 Mar 2018 10:45:13 -0500, you wrote:

>On Sat, 2018-03-03 at 03:53 +1300, Stephen Worthington wrote:
>> But you were talking about proxying an HTTPS URL.
>I assume you mean "not" above.  And sure, maybe one URL was http and
>not https, but that is just one example.  Proxy support has to work for
>all URLs, not just select ones.

No, I did not mean "not".  The URL you posted is HTTPS:

> Feb 28 09:18:50 pvr mythbackend: mythbackend[28709]: E TVRecEvent iptvtuningdata.h:251 (IsHLSPlaylist) IsHLSPlaylist - Open Failed: No suitable proxy found#012#011#011#011https://cbclivedai5-i.akamaihd.net/hls/live/567235/event2/CBOT/master1.m3u8

>> And it is possible
>> to proxy HTTPS properly - you have use a proxy that has a proper
>> certificate and load that certificate into your certificate store.
>I don't consider launching MitM attacks on my users "proper".  

I was not suggesting that you MitM anyone except yourself.  With the
proper firewall rules, just the traffic from mythbackend would be

>> Since you are doing the man-in-the-middle
>> yourself, with proper certificates, the other end does not have any
>> problems with the connection and you are not creating a security
>> risk.
>Except that every client that comes into my network needs to install my
>CA-impersonating certificate and (some) systems will complain about
>having "untrusted" certificates installed:

Not if you just intercept the traffic that needs intercepting.

>I don't want to train my users to ignore security warnings.
>On another note, what a MitM-transparent-proxy is actually doing is
>impersonating a trusted CA due to one particular weakness of the CA
>system which is that any CA can generate any certificate for any domain
>name.  I am sure you have seen the many stories in the news about this
>happening and the repercussions to the security of SSL (in general) due
>to it.  It is understood as a serious enough problems that CAs lose
>their "trustworthiness" because of it and end up going out of business.
>But also the point of the seriousness of it is that there are solutions
>to the problem in general underway.  Certificate pinning was thought to
>be a solution but is being deprecated, but is still out there, in
>Chrome and other browsers for at least the near future.  In it's place
>is Certificate Transparency which achieves the same goal of alerting
>users to CA impersonation.  MitM-transparent-proxy is going to trigger
>certificate pinning an certificate transparency warnings/errors. 
>Again, not wanting to train my users to ignore such warnings.
>The bottom-line is that I am not really interested in the rigmarole of
>transparent proxies and would just like systems configured to use
>proxies to actually work.  I suspect that in the case of MythBE (and
>QT) systems this is just not going to happen.
>I have actually been re-considering the value of a proxy in my network
>with the ever-increasing movement towards HTTPS.  This might just be another vote in the "trash it" column.

Your own HTTPS proxy does NOT impersonate any authority.  It has its
own certificates that you generate, normally using your own
"authority".  Anything that tries an HTTPS connection that is sent
through the proxy will see the proxy's certificate.  Unless it has had
that certificate installed as a user certificate (or a trusted
certificate), it will normally pop up a question about that, rather
than continue the connection.  The user then gets to choose whether
they want to accept that certificate, or not and kill the connection

For proxying mythbackend, the mythbackend box would need to have the
HTTPS proxy certificate installed at least as a user certificate, as I
am pretty sure mythbackend does not have its own certificate store. So
any other HTTPS traffic originating from that box that got diverted to
the HTTPS proxy would not do the certificate pop up.  So that would be
something to be wary of - you would have to make sure that
mythbackend's traffic was the only traffic that was transparently
redirected.  The way to do that is to run mythbackend in a different
network namespace from all the other processes on the box.  That
network namespace would be the only place the transparent proxy
firewall rules would be in place.  I think doing that would also
require that the mythbackend network namespace had a separate IP
address from the main network namespace.

More information about the mythtv-users mailing list