Quote:
I doubt the nexdef streams are going to go away, because they are at present used by the MLB.TV web client and are the focus of their attention. The rtmp streams are much more likely to be for the chop. (The web client does not happen to use the java nexdef plugin any more when accessing the nexdef streams except when in legacy/audio overlay mode, but that's a different issue.) |
Quote:
Quote:
|
Quote:
|
Quote:
|
Quote:
So I guess this is either an Ubuntu bug or a bug somewhere else that only Ubuntu (and maybe just 14.04) notices? And I guess the only thing to do is... wait for an update (and use the rtmp streams in the meantime)? That isn't a disaster for me, especially during spring training, but if anybody has any other thoughts on what might be going on I'd appreciate it. |
Quote:
|
I have Ubuntu 14.10 so there's another data point for you. If all else fails, the live CD works very well through VirtualBox if you use the install script to create the template with hardware acceleration for graphics. I don't know what the minimum requirements are but a relatively new machine like dual-core and 1 GB RAM or more should work for running it in virtual machine mode. The virtual machine itself is only a single core and 512 mb memory.
|
Well, I've done some more digging, and I think I've found something strange. The short version is: it looks like there is indeed a self-signed certificate in MLBAM's chain, which my 'broken' Ubuntu machines (sensibly?) don't trust, but which my 'working' Debian machine silently ignores. This is strange because it seems like my 'broken' machines are actually showing the expected behavior, while 'working' machines are not.
The longer version: On an up-to-date 'broken' Ubuntu 14.04, I used curl on the command line to download the url in the error message, with the same result: Code:
$ curl 'https://mlb-ws.mlb.com' Code:
$ wget 'https://mlb-ws.mlb.com' Code:
$ openssl s_client -connect mlb-ws.mlb.com:443 Then I checked on my up-to-date Debian Squeeze (now LTS) machine, on which mlbhls works as expected. I don't want to keep cluttering the post with output messages, but suffice it to say that the openssl s_client command above produced the exact same certificate chain as above, the same error 19 message, and the same hang afterwards. So this machine's openssl command was seeing the same error as the Ubuntu box. Then I tried curl on the Debian box: Code:
$ curl https://mlb-ws.mlb.com So, that makes it look to me like the Ubuntu boxes are refusing to accept a self-signed certificate, which seems like a reasonable thing to do, and the Debian box (and maybe all of your working setups?) are accepting it without complaint (which seems bad?). pajamian, your suggestion to have curl ignore the verification works a treat when I use curl on the command line, but doesn't seem to affect the behavior of libcurl (which is what mlbhls uses). But anyway, is it really a good idea to just disable a security warning (indeed, *all* security warnings that curl might raise)? Frankly, now I'm getting more worried about my Debian box silently ignoring cert errors than I am about getting mlbhls working... But maybe I'm overlooking something stupid here? Do other people see the same error when running 'openssl s_client -connect mlb-ws.mlb.com:443'? Is there some sort of new/old SSL exception that changes the expected behavior in this case? Can I or should I change the way libcurl handles this error? Sorry for a long post for a problem only I seem to be having, but if it makes sense to anybody else I'd appreciate it if you could let me know. In the meantime, I'm loving the RTMP streams! :D |
Quote:
|
Quote:
The root CA certificate is not supposed to be included in the certificate chain, various browsers already have it installed so it's not needed to include it twice. MLB is including it in the certificate chain, though and that appears to be confusing your version of libcurl (mine handles it just fine). It would appear that most SSL/TLS libraries can handle this minor infraction but some can't, so this is really an issue from MLB. From your end, I would try a different curl implementation (as daftcat originally suggested try the openssl flavor instead of the nss one or vice-versa). I'm not sure if there is anyone here who has a contact at MLB or knows how to file a bug report to get them to fix their server to not send the root certificate with the rest of the chain? Oh, incidentally, s_client isn't "hanging", it's connected to a http server which is now waiting for your input. Typing QUIT will tell the server to close the http connection. I normally include the QUIT on the command line when doing my diagnostics: Code:
openssl s_client -connect mlb-ws.mlb.com:443 <<<"QUIT" |
In addition to what pajamian said (that you don't need the root certificate in the server's announced certificate chain), I should check that in the non-working machines you have the root certificate ValiCert_Class_2_VA.pem or ValiCert_Class_2_VA.crt (or whatever ubuntu happens to call it) in both /etc/ssl/certs and /usr/share/ca-certificates/mozilla (the first is usually a symbolic link to the second). If you haven't, copy the certificate across from one of your working machines and run c_rehash.
|
Wow, terrific, thanks pajamian! I'm still a little fuzzy on some of the TLS details, but apparently unlike me you actually know what you're doing with this stuff, so I'm happy to take your word for it based on your diagnosis of the cert chain.
Unfortunately, I already am running the openssl flavor of libcurl (libcurl4-openssl-dev on Ubuntu 14.04), and I've also tried the nss and gnutils flavor with the same results. But the fact that wget shows the same behavior (on Ubuntu 14.04 only) makes me wonder if the workaround might be happening somewhere else? I suppose worst-case, I could go hunting through mlbhls's source to add the insecure flag to (at least) this particular curl call... But that seems neither easy nor a very good solution to an upstream problem, so any other suggestions of how to work around it would be appreciated! |
Quote:
Code:
sudo ln -s /usr/share/ca-certificates/mozilla/ValiCert_Class_2_VA.crt /etc/ssl/certs/ValiCert_Class_2_VA.pem Code:
$ curl 'https://mlb-ws.mlb.com' I guess that leaves me with three follow-up questions:
Thanks a heap for everyone's help on this, trying to understand that openssl stuff felt like reading hieroglyphics. Really glad I posted that output and that you guys knew what it meant and where to look for a fix. |
Oh yeah and I forgot to mention -- mlbhls works perfectly now, just in time for me to see Bob Uecker call the Cubs game! :D:D
Thanks again guys! |
Quote:
EDIT: Take care. It is legacy because it only has 1024 bits of encryption (see next post). Chris |
All times are GMT -5. The time now is 05:05 PM. |