HTTPS SSL certificate for source.ffmpeg.org is broken

[ahthovaikied]

The SSL certificate for source.ffmpeg.org as a invalid domain:

$ git clone https://source.ffmpeg.org/
Clonage dans 'source.ffmpeg.org'...
fatal: unable to access 'https://source.ffmpeg.org/': SSL: certificate subject name (*.videolan.org) does not match target host name 'source.ffmpeg.org'

$ curl -v https://source.ffmpeg.org/
* Hostname was NOT found in DNS cache
*   Trying 88.191.250.118...
* Connected to source.ffmpeg.org (88.191.250.118) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* 	 subject: OU=Domain Control Validated; OU=Gandi Standard Wildcard SSL; CN=*.videolan.org
* 	 start date: 2012-10-03 00:00:00 GMT
* 	 expire date: 2015-10-03 23:59:59 GMT
* 	 subjectAltName does not match source.ffmpeg.org
* SSL: no alternative certificate subject name matches target host name 'source.ffmpeg.org'
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: no alternative certificate subject name matches target host name 'source.ffmpeg.org'

See also ​https://www.ssllabs.com/ssltest/analyze.html?d=source.ffmpeg.org

As a result users who want to clone FFmpeg source tree, are forced to either use the insecure git://source.ffmpeg.org/, or a mirror like ​https://github.com/FFmpeg/FFmpeg.

[Carl Eugen Hoyos]

Isn't git inherently secure without https?

[ahthovaikied]

Replying to cehoyos:

Isn't git inherently secure without https?

For you, who have SSH access, yes. For anonymous users, no.
See ​http://git-scm.com/book/en/Git-on-the-Server-The-Protocols.

[Carl Eugen Hoyos]

I meant something else: Isn't the advantage of using https over http that you know the content of the transmission was not changed? You cannot change a git repository without anybody noticing because it would change the version hashes. Or do I misunderstand?

[ahthovaikied]

Replying to cehoyos:

Isn't the advantage of using https over http that you know the content of the transmission was not changed?

That is only one part of what SSL has to offer when done right: integrity. There is also authentication and confidentiality.
There is no point to guarantee the transmission was not changed, if you can not guarantee it is coming from the server you think it is.

Replying to cehoyos:

You cannot change a git repository without anybody noticing because it would change the version hashes.

That would only be seen if you try to push the compromised repository to a non compromised one.
An attacker could still setup a trivial MITM attack, alter the source code (and the hashes), and thus inject malicious code in the FFmpeg binary.

[Carl Eugen Hoyos]

Which binary?

[ahthovaikied]

Replying to cehoyos:

Which binary?

The one users obtain from compiling untrusted source code.

[Carl Eugen Hoyos]

Do I understand correctly that if the issue gets fixed (can we fix this at all or does videolan have to fix it?) you would trust the downloaded source without comparing the hashes? Is it so unlikely that the server gets hacked?
Anyway: I suggest you test git.videolan.org instead of source.ffmpeg.org which will hopefully fix the issue. (Please don't suggest this solution to others if it works for you.)

[ahthovaikied]

Replying to cehoyos:

Do I understand correctly that if the issue gets fixed (can we fix this at all or does videolan have to fix it?) you would trust the downloaded source without comparing the hashes?

Let's be realistic here, you can not rely on people manually comparing the hashes (with what anyway?). I bet most people who clone the source are using scripts anyway.
By the way, Git commit hashes are SHA1 which is not considered cryptographically strong, and were never intended to be used for security purpose in Git.

Replying to cehoyos:

Is it so unlikely that the server gets hacked?

It's not, but it's a different attack surface.

Anyway: I suggest you test git.videolan.org instead of source.ffmpeg.org which will hopefully fix the issue. (Please don't suggest this solution to others if it works for you.)

git.videolan.org fixes it.

I'm no HTTPS specialist but my understanding is that the problem comes from the way you redirect from source.fmpeg.org to git.videolan.org.
You already have a valid certificate for *.fmpeg.org, so this should only be a matter of configuration.

[Michael Niedermayer]

Where did you find a https url pointing to source.ffmpeg.org ?

We do list https urls on our download page which work:
​https://github.com/FFmpeg/FFmpeg

Also, there is no redirection, the source subdomain simply points to the videolan server as they provide the main git for us.

Doing some kind of redirection tricks would defeat the security of SSL and or confuse the user if its possible at all. The only sane option i see would be to move the main git repository to one of our servers and use our certificate on it. Iam not against that but its alot of work and iam lazy

Iam marking this as invalid as without a https url pointing to source.ffmpeg.org, it cant be expected that there is working https there

But feel free to open a ticket about moving the git repo to our server if you like ...