4

Okay, suppose I have been implementing paypal IPN, and my server will respond by verifying with "https://www.paypal.com/cgi-bin/webscr" and got the VERIFIED message back.

First, if my server connects to paypal using SSL, will it guarantee that there'll be no man in the middle attacks, such as someone sending the fake IPN commands, and intercepting my IPN verification messages and sending a fake VERIFIED message?

Second, would having my own SSL certificate help in security in any way? They're not that expensive, but just wondering what their actual significance is. I suppose it might be useful for getting that green bar in the users' browser at any rate.

AviD
  • 72,138
  • 22
  • 136
  • 218
kamziro
  • 277
  • 1
  • 5
  • 2
    Note that `"that green bar in the users' browser"` is only for the more expensive EV SSL certs, not any regular SSL cert. – AviD Jul 08 '11 at 09:03
  • Thanks, information appreciated. Looks like they average around $150, I suppose they're *probably* worth the price for e-commerce sites.. – kamziro Jul 08 '11 at 09:25

3 Answers3

5

  1. This should be secure against man-in-the-middle attacks if your machine checks that it has received a valid certificate for Paypal from its correspondent.

    Be warned that some SSL libraries leave it up to you to implement/request this check, so you will need to carefully confirm that your code is performing that check. (Since your machine is initiating the HTTP request to Paypal, for purposes of the SSL protocol, your machine is the client and Paypal is the server.)

  2. No. Buying your own certificate doesn't help with this communication with Paypal, when your machine is initiating a HTTP request to Paypal. (However, there might be other reasons why it is good for your users to connect to your site via HTTPS rather than HTTP, which does require a cert.)

Community
  • 1
D.W.
  • 98,420
  • 30
  • 267
  • 572
3

SSL is immune to MITM as long as one of the peers is authenticated. Normally this is the server end of the transaction, in this case Paypal), unless someone has broken the client end 'just trying to get it working', e.g. by accepting anything in the way of a server certificate.

user207421
  • 245
  • 1
  • 7
  • 2
    @ejp @kamziro: D.W's answer is much better. The meaning of "server" here is ambiguous, since in this case a web server (with something for sale) is connecting to the Paypal server. Furthermore, each party in the communication needs to do their own checking. It would make no sense for one party to say "the other side authenticated me so there is no risk of MITM". Without authenticating the other end, you have no reason to trust who it is, or that it verified anything. So make sure they use a CA that YOU trust. See also http://security.stackexchange.com/q/2268/453 – nealmcb Jul 07 '11 at 22:06
  • 1
    @nealmcb: I disagree, and further @EJP's second sentence of his two sentence answer is all about doing the trust checking correctly. I fail to see any way to read into his correct statement about blocking MITM attacks an endorsement of one-sided authentication. If the service running on the SSL server needs to authenticate the client it will surely do so, probably with a usename and password rather than SSL's client authentication feature. – President James K. Polk Jul 08 '11 at 03:13
  • @gregs: The problematic part is the first sentence, which together with the second implies that even if the client doesn't properly authenticate the server, that MITM could be avoided if the server instead authenticated the client. But doing so, especially with a password as you suggest, would provide no MITM immunity. – nealmcb Jul 08 '11 at 04:04
  • 1
    Please be careful with statements like that. SSL is immune to MITM as long as: one of the peers has a key pair; the peer that has a key pair has his public key, or the public key of a transitive signer of his public key, pre-shared with and trusted by the other peer; the peer that has a key pair and all transitive signers of his public key up to the public key that is pre-shared with and trusted by the other peer keep their private keys confidential and ensure they are not stolen, disclosed, misused, etc.; – yfeldblum Jul 08 '11 at 13:28
  • 1
    all the key pairs in the chain are long enough; the peer with the key pair supports only strong algorithms with long enough keys; there are no exploitable flaws in the software performing the cryptography; and more conditions besides. – yfeldblum Jul 08 '11 at 13:28
  • @nealmcb The first sentence above is more or less straight out of RFC 2246. If you disagree with that, take it up with them. – user207421 Jun 11 '12 at 02:12
  • Where do you read that? Read [RFC 2246 F.1.1](http://tools.ietf.org/html/rfc2246#appendix-F.1.1) which is very clear that the server in particular has to be authenticated. And as yfeldblum notes, check out the many risks noted there of using earlier versions of SSL, of rollback attacks, and of not doing the sort of checking which as D.W. notes is not done by some libraries. – nealmcb Jun 11 '12 at 16:55
  • @nealmcb OK. Java JSSE (at least) provides the ability to reverse server and client handshake roles. That's what I would mean by 'at least one peer' and also what I mean by 'normally this is the server end'. – user207421 Jun 12 '12 at 07:58
-1

@kamziro: i am not sure about paypal IPN commands..but in general, if you want to avoid man in middle attacks over SSL attack, you would need following:- i) SSL involving client authentication which means Paypal should authenticate your server's certifciate during client certificate authentication phase. ii) You would use perhaps Paypal SSL certificate to encrypt IPN command and can digitally sign with your private key which can be verified at paypal side for authenticity of sender.