Bitcoin Forum
May 24, 2024, 03:52:07 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: For a website taking payments with bitcoins, better: IP or bitcoin addresses?  (Read 17167 times)
D҉ataWraith
Member
**
Offline Offline

Activity: 60
Merit: 10



View Profile
May 31, 2010, 09:06:54 AM
 #21

As for the attacks on websites with BC addresses, you may deface them, and you may spoof even without the server's Private Key. Normally people don't look to the CA, so as long as the CA is recognized it will ring no bells - and within this "world", specially for Tor users, Verisign Certificates aren't the normal thing, but CACert and other free services alike (means also many users are already used to press "Continue" on invalid certificate flags).

I'm by no means an expert on this, but I think even a free certificate includes a "this is for website www.example.com"-field, and you can only get a certificate if you actually control that domain (can receive email sent to the domain), so I don't think forging that is trivial. Firefox, for example, explicitly pops up a warning if a certificate is for a domain other than the expected one.

The remaining weak link then is DNS, but while possible, it is non-trivial to forge that, especially when you're watching the destination-page, and can't know who is going to want to visit it beforehand. Also, DNSSEC is slowly becoming the norm, so that possibility also goes out of the window within a few years.

The reason why I bring up TOR is that bitcoin complements it very well. TOR preserves anonymity, and bitcoin allows for anonymous transactions.

Quote
Edit:
To not mention the obvious: If you know the destination's IP Address why on Hell you would need to use Tor to pay?? And if the address would be something like <some unreadable hash>.onion then you wouldn't need SSL, because inner Tor data is already crypted.

Suppose someone doesn't want to know the payee who he/she is? Without TOR the IP address is revealed, which, at the very least allows the other party to know the approximate geographical location.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
SirArthur
Member
**
Offline Offline

Activity: 183
Merit: 43


View Profile
May 31, 2010, 09:42:41 AM
 #22

Sure does, that's what a certificate does: Hey! You're on www.somewebsite.com and the data is crypted.
The question is that, imagine somewebsite is meant to be at 123.123.123.123 and someone else spoofed DNS for it to resolve to 123.123.123.124, then your browser will believe it is at www.somewebsite.com - even if it's phishing.
And for free certificates, they might include the security they want, but no browser recognizes their root CA's, so it makes them as worthable (and will raise the very same alerts) a self-signed certificate.

DNSSEC is yet another piece of junk. That probably would never come to be nothing but a project. Issues of practical life, negociating crypt algorithms reduces performance and DNS is a really heavy duty service. So, if someone tries to implement DNSSEC as a standard, internet would probably become as slow as Tor is.

And if someone doesn't want the one he's paying to to know his address, probably the person that's receiving the payment doesn't want to show his address either. Therefore they simply DON'T use DCC Pay, but P2P Pay. Easy... as long as both options are there.

I'm up to choices not to paranoia. Paranoia in security isn't of any value add, paranoia is just that... paranoia. Reduces life quality, grants nothing and prevents people from live.
Yes, someone may steal your data, as someone may steal your wallet on the bus with the very same outcome. There're some security elementals, but you can't keep looking over your shoulder (specially because you probably will miss to see the electrical post in front of you).  Grin
D҉ataWraith
Member
**
Offline Offline

Activity: 60
Merit: 10



View Profile
May 31, 2010, 01:06:33 PM
 #23

Sure does, that's what a certificate does: Hey! You're on www.somewebsite.com and the data is crypted.
The question is that, imagine somewebsite is meant to be at 123.123.123.123 and someone else spoofed DNS for it to resolve to 123.123.123.124, then your browser will believe it is at www.somewebsite.com - even if it's phishing.

How would the attacker get hold of a valid certificate that claims it's for www.somewebsite.com without actually controlling said domain?

Quote
And for free certificates, they might include the security they want, but no browser recognizes their root CA's, so it makes them as worthable (and will raise the very same alerts) a self-signed certificate.

Not necessarily. StartCom, for example, is recognized as a valid CA by almost anyone (Opera being the exception). CACert ist also included in popular Linux distributions (e.g. Debian).

Quote
DNSSEC is yet another piece of junk. That probably would never come to be nothing but a project. Issues of practical life, negociating crypt algorithms reduces performance and DNS is a really heavy duty service. So, if someone tries to implement DNSSEC as a standard, internet would probably become as slow as Tor is.

Ehm. DNSSEC _is_ a standard, and the root servers and many TLDs are already using it, although it will only become fully functional later this year. It's true that it is not as efficient as it could be (and was rightly criticized thus by people like Daniel J. Bernstein), but with .com, .net and .org adopting it within the next year or two, I'd pretty much say it's a done deal.

Quote
And if someone doesn't want the one he's paying to to know his address, probably the person that's receiving the payment doesn't want to show his address either. Therefore they simply DON'T use DCC Pay, but P2P Pay. Easy... as long as both options are there.

Well, I was working with the premise of IP payment, because that's what you brought up in the snippet I replied to with that paragraph. Of course you can just use a Bitcoin address (unless the payee wants you to pay DCC-style...)

Quote
I'm up to choices not to paranoia. Paranoia in security isn't of any value add, paranoia is just that... paranoia. Reduces life quality, grants nothing and prevents people from live.
Yes, someone may steal your data, as someone may steal your wallet on the bus with the very same outcome. There're some security elementals, but you can't keep looking over your shoulder (specially because you probably will miss to see the electrical post in front of you).  Grin

^^

The thing with security is that you have to be aware of what _could_ happen. I don't walk around with 1000$ in my wallet, precisely because it could be stolen, for example. If Bitcoin becomes an accepted currency, attacks *will* happen -- just think of all the phishing that's going on with Paypal and normal banks. If there's a way, it will be exploited by criminals.

1NvcPV6xi6yqo5yg8aWSkNdasPSAsGtt1m
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2217


Chief Scientist


View Profile WWW
May 31, 2010, 04:16:59 PM
 #24

To get back to the original question, paying to a bitcoin addresses displayed on an https: webpage secured with a valid certificate is better.

When the bitcoin client supports secure connections to IP addresses, then paying to an IP address displayed on an https: webpage secured with a valid certificate will be just as good (security-wise, anyway).

Bitcoin doesn't try to solve the "am I paying who I THINK I'm paying problem" -- we need HTTPS and signed certificates and DNSSEC for that (or something similar).  Bitcoins are a small but really important piece of the payment puzzle...

How often do you get the chance to work on a potentially world-changing project?
SirArthur
Member
**
Offline Offline

Activity: 183
Merit: 43


View Profile
May 31, 2010, 08:31:20 PM
 #25

D҉ataWraith,

DNS is the simplest of protocols, all it does is to have a database, cache or forward to next DNS a request.

Basically goes like this:

you type: nslookup www.somesite.com

You computer goes to your resolv.conf or network config, according to your OS, pick your Nameserver and say:

«Hey! Dude! What the hell means www.somesite.com?»

The Nameserver looks it up if has it on its cache or database will reply: «Yo! Man! That's 123.123.123.123», if not will look it up and reply if find or will say «M'a man, there's no such a thing on the internet as far as I can tell!».

However someone may spoof the Nameserver and reply to your computer with a wrong address, which your computer will take for "the real deal".

The issue with DNSSEC is that, thus it's usable for root and authoritarian nameservers, it isn't for clients.
The difference?
Normally you must read on a ns lookup:
Reply without authority
www.somesite.com 123.123.123.123

This means the server that's replying to you knows where www.somesite.com is, but it's not the nameserver for such domain. - This is what your ISP NS's do normally.
On the other side you've the authority nameservers, means those whose the domain is registered to. Those update the root servers and yes, between those two, makes perfect sense update the root servers under a secure line to prevent some other nameserver as present itself as an authority to a domain it's not - which would spoof the address internet wide.

Now... clients does A LOT of DNS requests, it's normal that when you visit a page that page to have items stored somewhere else. For each "some where else" your computer does a DNS request... now just imagine if it has to negociate a certificate with the nameserver before.

As for attacks, it's something you must count on, but I do prefer to have users aware of the danger rather than go Fascist like imposing limitations to what they can do.
Security has to be moderate by the hazard, you probably would check your wallet every minute on a bus to see if it's still on your pocket if you carry like $1000, but you don't if you carry just 1 or 2 bucks. Likewise it would make the same sense to protect a computer bank-like if the user just has there a couple of pirate MP3.  Grin

Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!