4 ms·

It's a self-signed cert - and just as encrypted as it would be with a traditionally signed cert. This is the half of SSL that I care about - I really don't car

by nmcfarl 12y ago

It's a self-signed cert - and just as encrypted as it would be with a traditionally signed cert. This is the half of SSL that I care about - I really don't care if you handed your money over to some organization that verified you have a working phone number. -- Actually it doesn’t appear to be a self-signed cert in this case - or even necessary. That cert is playing fine with both safari, and GNU Wget 1.14.

pyre 12y ago
Older versions of wget didn't like wildcard certs (IIRC). I remember this being an issue around the time that github.com when https-only a few years ago. It's possible that this is necessary here (on older versions of wget), or that using '--no-check-certificate' is a bit of a cargo-cultism by the author (who learned to use it, but doesn't know why and when usage makes sense).
asveikau 12y ago
I guess you won't mind when I put my own self-signed cert there, then.
deleted 12y ago
[deleted]
colechristensen 12y ago
When you're installing software from https, you're not trying to make sure nobody can see the contents of the message (it's publicly available), you're trying to ensure that there's no man in the middle tampering with your software en route. A self signed cert which you can't independently verify is entirely worthless in this context. A man in the middle could simply substitute his own self signed cert and you'd be non the wiser. You use signed certificates so that a vendor can prove their identity reliably. I care that the software I'm downloading actually comes from the owner of the domain I'm downloading it from. I can't do that with a self-signed cert.
- nmcfarl 12y ago
  So the argument here is that we are trusting github not the author of the software. And that way we can trust the code audit we do on GitHub to be the same as the downloaded software. So we don't have to use our own software tools to do that audit, we can look at the code on github. I can see that being a valid argument for github however for self-hosted non-famous authors the fact that they are who they say they are means nothing to me°. And as such I'm going to have to audit the software on my box regardless. (Or just forget about auditing and trust of the world is a safe place - which is what most people do anyhow - and if you are doing that you don't believe in mitm's anyhow.) °also I would argue that they signed certificate doesn't prove that anyhow. And state actors can forge these anyhow, so we are now talking about people who control your pipes, but not the government, and who hasn't hacked the end point. And
  - colechristensen 12y ago
    The point is, if you don't verify ssl certificates, you might as well use http. Https with self signed certs provides you no security in any circumstances downloading public software. Self-signed certificates and http connections are trivially intercepted and forged (ever used wifi in a public place?) Signed certificates provide limited proof of identity true, but they can't be forged by jokers hijacking the wifi in a coffee shop.
    - deleted 12y ago
      [deleted]
epsylon 12y ago
A self-signed is worthless since it can be trivially MITM'd.

by nmcfarl 12y ago

pyre 12y ago

Older versions of wget didn't like wildcard certs (IIRC). I remember this being an issue around the time that github.com when https-only a few years ago. It's possible that this is necessary here (on older versions of wget), or that using '--no-check-certificate' is a bit of a cargo-cultism by the author (who learned to use it, but doesn't know why and when usage makes sense).

asveikau 12y ago

I guess you won't mind when I put my own self-signed cert there, then.

deleted 12y ago

[deleted]

colechristensen 12y ago

When you're installing software from https, you're not trying to make sure nobody can see the contents of the message (it's publicly available), you're trying to ensure that there's no man in the middle tampering with your software en route. A self signed cert which you can't independently verify is entirely worthless in this context. A man in the middle could simply substitute his own self signed cert and you'd be non the wiser. You use signed certificates so that a vendor can prove their identity reliably. I care that the software I'm downloading actually comes from the owner of the domain I'm downloading it from. I can't do that with a self-signed cert.

nmcfarl 12y ago
So the argument here is that we are trusting github not the author of the software. And that way we can trust the code audit we do on GitHub to be the same as the downloaded software. So we don't have to use our own software tools to do that audit, we can look at the code on github. I can see that being a valid argument for github however for self-hosted non-famous authors the fact that they are who they say they are means nothing to me°. And as such I'm going to have to audit the software on my box regardless. (Or just forget about auditing and trust of the world is a safe place - which is what most people do anyhow - and if you are doing that you don't believe in mitm's anyhow.) °also I would argue that they signed certificate doesn't prove that anyhow. And state actors can forge these anyhow, so we are now talking about people who control your pipes, but not the government, and who hasn't hacked the end point. And
- colechristensen 12y ago
  The point is, if you don't verify ssl certificates, you might as well use http. Https with self signed certs provides you no security in any circumstances downloading public software. Self-signed certificates and http connections are trivially intercepted and forged (ever used wifi in a public place?) Signed certificates provide limited proof of identity true, but they can't be forged by jokers hijacking the wifi in a coffee shop.
  - deleted 12y ago
    [deleted]

epsylon 12y ago

A self-signed is worthless since it can be trivially MITM'd.