Topic: bitcoin.org and sourceforge.net are not running on https - page 2. (Read 2247 times)

I know how PGP works. But I don't personally know any of the devs so it is impossible for me to verify the authenticity of the keys, and I don't have a web-of-trust that would lead me to them.

Then please read about PGP and check this page: all devs PGP keys are listed there

Edit: I updated the PGP description link to the more specific one, sorry for initial ambiguity

Edit2: bit-torrent protocol does not provide more security than http. It provides only stronger data integrity apart from possible higher download speed.

Edit3: The use of ssl/tls encrypted links between the nodes does not change the picture unless you have a Certificate Authority that issues certificates for each node in the network. This would kill the overall idea of the bitcoin network decentralization

Most people, including me, are unable to audit the source code. I trust the people holding the bitcoin.org (ie. Gavin and other bitcoin devs) so I'm happy to use the binary (also with the fact that I believe some other people will try to compile and compare the binary). But how do I know the PGP public key is legit at the first place, if it is not linked to bitcoin.org in any way?

The bottom line, IMO, is to run bitcoin.org over https, and offer the binary hashes. The binary itself may be transmitted with http. A better way is to offer a torrent for the reference client (through https, of course).

The message is protected by the PGP signature, thus you have to believe that the PGP infrastructure is not broken. This way you may be sure that the file you downloaded has been crafted by the person who signed the message.

BTW, how do you believe that your bitcoin-qt (provided you inspected its source code) is not talking to the bot net which in turn aims to steal your bitcoins?

So you are trying to verify an unprotected file with unprotected message on the same site? And how do we know the PGP public key is legit? It just doesn't make any sense.

The best way, of course, is to download, audit and compile the source code. But most users won't be able to do this.

github is running on https

sorry, I did not got who did you ask your question, so here is my response:

https is not useless, ofc. You know, that it is possible to put the nail in place with microscope, but it is much more correct to do it with a hammer.
If the _static_ content to be verified could be verified offline using sha/pgp scheme then this approach should be used as it conserves resources. The Earth resources.
This is MHO.

Okay, do you want to argue that https is useless and we should abandon it?

Using https may not help us to defend against governmental attack, but it definitely makes hackers' life much harder.

Yes, you are right, that you cant't be sure if your computers security has been compromised. But also it is not possible to "virtualize" the whole internet. If the attack is targeted specifically at you, and thus, it is conducted under a human control, then with some extent of probability that human would succeed to make you believe your eyes. But "regular" viruses would fail to make your reality completely virtual.

If your computer is compromised, it's the end of the world already.

I'm serious here. A virus that can modify webpages clientside can also break md5/sh1/sha256 checksum executables. It can corrupt your GPG executable. A virus can do anything.

This doesn't mean HTTPS is useless. Any virus that can break HTTPS security can break GPG security too.

@jl2012, @dree12, although I would not argue that the MITM problem has place, I would like to ask you, what kind of OS you are using? This is a rhetorical question. Let's assume that many people are using Windows and - even more - they are using IE. Everyone knows that it has many flaws and security problems. So the average user installs some antivirus protection on his computer. But even the up to date AV databases are not guarantee 100% defense. Some time a new breaches found by malicious users and they produce a new viruses that are not identified by the present AV tool-kits  for a while. Then let's imagine that one of these bad guys targets specifically at satoshidice and makes a virus that changes the content of the page displayed at client side, directly in the browser. Then it has no sense if the page have been received with http or with https. So, some times the use of https is an overkill that would lead to growing expenses at both sides - the content providers one and at the client as https ultimately disables any intermediate caching of the information transferred. The only way to protect yourself from unwanted financial loses is to double check the addresses you are sending your coins by all available means (browse blockchain, e.t.c), verify md5/sha1/sha256 check-sums and pgp-signatures usually attached to open source sw published in open repositories, e.t.c.

For example, the download page of the bitcoin-qt reference client has a clear link to the signed sha256sums of the currently available version:

http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.5/SHA256SUMS.asc/view :


Usually such a measure is enough to detect any tampered file. So there is no reason indeed to distribute it over https.

bitcoin.org is hosted on GitHub, which doesn't support HTTPS.


The Chinese government also controls several certificate authorities, so they can bypass HTTPS anyway.

The sites for Armory and Electrum are also not running on https

I guess this is discussed somewhere else: who is holding and paying for bitcoin.org and bitcoin.net? Both were registered by Satoshi but bitcoin.net is now directed to a parking site and will expire in August 2016. I guess bitcoin.org is held by Gavin?

Many people don't realize the severity of this problem. SatoshiDICE also doesn't use HTTPS, so a MITM can change the addresses to whomever. Any Bitcoin business that displays addresses should be using HTTPS, and any client download website should as well.

I put this here because this is actually related to the security of the reference client.

Without https, MITM attack is really simple. For example, the Chinese government is notorious for DNS hijacking. Although the bitcoin-qt windows package is signed by bitcoin foundation, it is really easy to establish another bitcoin foundation inc. in another country and apply a legit cert for it.

Is there any reason not to run bitcoin.org on https, and host the binary of reference client on sf.net? It sounds quite irony as PKI is implemented in the payment protocol while the client itself is not properly protected by this.