[Live-devel] [patch] Authentication hiccups

Tomasz Pala gotar at polanet.pl
Wed Nov 5 01:41:43 PST 2014


On Sat, Nov 01, 2014 at 14:15:20 -0700, Ross Finlayson wrote:

> It seems, however, that there may be a bug in your RTSP server,
> because I don't think this should be happening:
>
>> -> Sending request: PLAY
>> <- RTSP/1.0 401 Unauthorized	WWW-Authenticate: Digest
>> -> Sending request: PLAY	Authorization: Digest
>> <- RTSP/1.0 455 Method Not Valid In This State
> 
> I don't understand why your server would first send back a "401
> Unauthorized" response, but then, after the client followed up with
> a valid "Authorization:" header, respond "455 Method Not Valid In
> This State".  I suggest filing a bug report for your server.

I agree, this should not happen, as there is no reason to invalidate
SETUP with 401 in-between. My guess is that there is some error in
state machine flow in the server, especially when it keeps my params (at least
the starttime value I've set), but holds down playback.

This is HQVision HQ-DVR0401HD960, an importer-branded Hikvision OEM platform,
so it's not oficially supported and I don't even know the original
device symbol to refer to fill bug report. Well, I'm not even sure if
it's firmware origins from Hikvision or maybe some other 3rd party.
Anyway, these devices are as popular as cheap, so this bug is probably
widespread. It didn't pop up before probably because people use web
inferface (with it's plugin - considering amount of Linux-only users) or
some dedicates PSIA software or are not aware that PSIA allows them to
use RTSP directly. But even if this bug would be fixed, firmware upgrade
procedure is not as straightforward as usuall due to huge number (dozens)
of importer brands on the market, without their own web pages, without
any support (warranty limited to replacing device or money payback), so
after all it's best to have robust client implementation.

>> One more suggestion if I might, that it would be nice to be able to
>> forcefully disable Basic auth.
> 
> No, I don't want to do this.  If a server is foolish enough to
> request Basic Authentication, then the client should use it.  (Few

I was thinking about preventing MITM attacker degrading auth to Basic.
Currently any RTSP client is vulnerable to exposing full credentials in
plain-text (almost), as there is no way to authenticate server first.
The only solution is to use firewall with deep packet inspection to
block Basic responses, which is way too hard to be widely usable.

And if not available at runtime (which in turn requires client apps to
follow), maybe an option to disable Basic entirely at buildtime?

-- 
Tomasz Pala <gotar at pld-linux.org>


More information about the live-devel mailing list