Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
Let's say I have a website isellchicken.com, this site needs to be able to collect sensitive user information like credit card details. This site will not process the information, but will send it to another site, processpayment.com which uses SSL. Does isellchicken.com need to run SSL as well? Or is the connection encrypted just because I am posting to a site that runs SSL?
In case you are wondering, the form tag would look like this:
<form action="https://processpayment.com" method="post">
With regards to payment data, you have to understand that there are security-focused answers and compliance-focused answers.
In short, it depends. Sure, you can post/redirect users to an HTTPS site from a HTTP site but whether such a method is acceptable depends on the type of merchant you are. Also, whether such a method is "secure" becomes less relevant when you factor in PCI compliance mandates. The question then becomes is the method compliant and whether you want to meet the the minimum compliance mandates or whether you want to implement more controls to increase the security posture/reduce risk. And whether something is compliant depends on whether you have a say or not. This depends on how much credit card transactions you process per year.
Let's say that you're a merchant (I'll use "you" interchangeably) with your own merchant ID number. You accept credit card payments but have chosen to outsource the payment system. The merchant, you, is still responsible for maintaining PCI compliance. If your acquiring bank asks you to submit a Self Assessment Questionnaire, you are required to complete it or risk paying a higher per-transaction fee, penalties, both, or risk losing your ability to process card data. If you process a bunch of credit card transactions - over 6 million visa or 6 million mastercard or 2.5 million amex per year, then you'll be subject to more stringent audit requirements including a yearly audit by an external PCI-certified Qualified Security Assessor (QSA).
If you don't process a lot of credit card transactions, you don't need to be audited by a QSA. You can just submit a SAQ. In which case, the merchant and management assert to meeting the PCI Data Security Standards. However, if you fall into a class that requires a yearly audit, then such a question as whether you can do an HTTPS post from an unsecured form and how you implement the redirect will be assessed as a pass/fail by the QSA.
As ewanm89 comments, using a plaintext page to redirect users to a secure payment gateway is subject to a MITM attack. Anyone with a clever setup can easily change the destination from processpayment.com to givemeyourcardnumber.com. The clever attacker can even implement a SSL certificate from a public CA so the user doesn't get any popups.
In the end, it's probably better to find out whether you are subject to compliance mandates and if so, to ask whether such a method is compliant or not (the general answer is that it depends - you have to be able to justify the how and why). Second, ask yourself whether you're willing to accept the risk and whether it makes sense (or makes no sense) to spend the extra $$ to get an SSL cert to encrypt more content (encryption also costs CPU cycles).
It's a long answer but when you take into account payment data, the correct answer to even the simplest question can become quite hairy.
Yes, the page that renders the form needs to use SSL as well as the target. If the form page does not use SSL, an attacker will be able to manipulate it during transmission.
You should not teach people to enter sensitive information on non SSL pages
