SSL protocol via custom module?

Hi

I have bought a â€=98well knownâ€=99 shopping cart program which I'=
m trying
to use with a â€=98well knownâ€=99 payment service provider.

There is unfortunately a problem with a Perl script not functioning
that each company says is the fault of the other. I am trying to
determine which one is correct ï=8C

The payment service provider says that in order for the process to
work, the server hosting my shopping cart must have SSL support. This
is apparently as the process uses a POST to send a simple
acknowledgement back to an HTTPS website, for handshaking purposes. The
payment service provider says that as the hosts system is a Linux box
it requires crypt::SSLeay and port 443 open.

However after a week of pushing the cart company they now say that that
SSL support is not required as their own module, an sc.pm file in
stored in the cgi-bin uploaded during the cart upload provides the SSL
support.

Searching for their scripts for lines like â€=98new HTTP::Request
"POST","url"; certainly draws a blank.

The shopping cart scripts appear to post the information by calling a
function
::HTTPS_SendAndReceive('www.xxxx.com', 443,
'/xxx.dll/apc/apc', $sPostedData, 'POST', $::TRUE, $ssl_socket);

This seems to use another object in the a .pm file that seems to have
a lot encryption going on ie #
# Construct the MD5 object
#
$Self->{_MASTER_MD5} =3D instantiateMD5Object();
#
# Construct the SHA1 object
#
$Self->{_MASTER_SHA1} =3D instantiateSHA1Object();
#
# Some more initialisation
#
$Self->init();



My questions are this:
1) In your opinions is it possible to implement a function to replace
the POST command so that simple data can be sent to an HTTPS site.
2) If the answer is yes, would it require the Perl MD5 module?
3) If yes is it enough to have the module in
/usr/lib/perl5/site_perl/5.6.1/MD5.pm like my host says it is
4) Would all of the above negate the need for a module like
crypt::SSLeay?


Please reply with as much detail as possible as I am the middle man
between the payment provider, shopping cart and host. And they seem to
find it impossible to talk to each other.

Pete
=20



/usr/lib/perl5/site_perl/5.6.1/MD5.pm

Re: SSL protocol via custom module?

petesouthwest@hotmail.com wrote:
>
> I have bought a ‘well known’ shopping cart program which I'm trying
> to use with a ‘well known’ payment service provider.

So they provide support and documentation about how to use it, and you
read the documentation fully before buying.

> There is unfortunately a problem with a Perl script not functioning
> that each company says is the fault of the other. I am trying to
> determine which one is correct 

Whose Perl script?

> The payment service provider says that in order for the process to
> work, the server hosting my shopping cart must have SSL support. This
> is apparently as the process uses a POST to send a simple
> acknowledgement back to an HTTPS website, for handshaking purposes.

Define "must have SSL support"? Able to make an SSL (HTTPS) outgoing
call, or be listening for an incoming HTTPS connexion? I presume your
process opens a connexion to them using HTTPS, so any handshaking can be
done over that - I can't see why they should try to initiate a call back to
another listener - that would be overly complex, unnecessary and silly.

> The
> payment service provider says that as the hosts system is a Linux box
> it requires crypt::SSLeay and port 443 open.

Needing port 443 open is for HTTPS - nothing to do with Linux. MS
Windows and MacOSX would need the same.

> However after a week of pushing the cart company they now say that that
> SSL support is not required as their own module, an sc.pm file in
> stored in the cgi-bin uploaded during the cart upload provides the SSL
> support.
>.....
> My questions are this:
> 1) In your opinions is it possible to implement a function to replace
> the POST command so that simple data can be sent to an HTTPS site.

POST does send simple data. Are you asking "can I send to an HTTPS site
without using an SSL component of some sorts". If so the answer is no.

> 2) If the answer is yes, would it require the Perl MD5 module?
> 3) If yes is it enough to have the module in
> /usr/lib/perl5/site_perl/5.6.1/MD5.pm like my host says it is
> 4) Would all of the above negate the need for a module like
> crypt::SSLeay?

No - MD5 is not a secure transport layer.

> Please reply with as much detail as possible as I am the middle man
> between the payment provider, shopping cart and host. And they seem to
> find it impossible to talk to each other.

Get the *exact* requirements from the payment service provider (you will
be paying them, so they should be able and willing to help you).

Get them clear in your head.

Then remember that your ISP is not going to change their practices for
your software problems. Either you can implement it now, or you will need
to find another ISP who can fulfill the requirements.


--
Just because I've written it doesn't mean that
either you or I have to believe it.

Re: SSL protocol via custom module?

On 08/04/2006 12:28 PM, petesouthwest@hotmail.com wrote:
> Hi
>
> I have bought a ‘well known’ shopping cart program which I'm trying
> to use with a ‘well known’ payment service provider.
>
> There is unfortunately a problem with a Perl script not functioning
> that each company says is the fault of the other. I am trying to
> determine which one is correct 
>
> The payment service provider says that in order for the process to
> work, the server hosting my shopping cart must have SSL support. This
> is apparently as the process uses a POST to send a simple
> acknowledgement back to an HTTPS website, for handshaking purposes. The
> payment service provider says that as the hosts system is a Linux box
> it requires crypt::SSLeay and port 443 open.
>
> However after a week of pushing the cart company they now say that that
> SSL support is not required as their own module, an sc.pm file in
> stored in the cgi-bin uploaded during the cart upload provides the SSL
> support.
>
> Searching for their scripts for lines like ‘new HTTP::Request
> "POST","url"; certainly draws a blank.
>
> The shopping cart scripts appear to post the information by calling a
> function
> ::HTTPS_SendAndReceive('www.xxxx.com', 443,
> '/xxx.dll/apc/apc', $sPostedData, 'POST', $::TRUE, $ssl_socket);
>
> This seems to use another object in the a .pm file that seems to have
> a lot encryption going on ie #
> # Construct the MD5 object
> #
> $Self->{_MASTER_MD5} = instantiateMD5Object();
> #
> # Construct the SHA1 object
> #
> $Self->{_MASTER_SHA1} = instantiateSHA1Object();
> #
> # Some more initialisation
> #
> $Self->init();
>
>
>
> My questions are this:
> 1) In your opinions is it possible to implement a function to replace
> the POST command so that simple data can be sent to an HTTPS site.

This would probably be very hard, and your debugging attempts
might get you locked out of the payment service temporarily.

> 2) If the answer is yes, would it require the Perl MD5 module?

Yes

> 3) If yes is it enough to have the module in
> /usr/lib/perl5/site_perl/5.6.1/MD5.pm like my host says it is

Most likely.

> 4) Would all of the above negate the need for a module like
> crypt::SSLeay?
>

If you write the equivalent of Crypt::SSLeay, that would
eliminate the requirement of Crypt::SSLeay.

>
> Please reply with as much detail as possible as I am the middle man
> between the payment provider, shopping cart and host. And they seem to
> find it impossible to talk to each other.
>

It sounds like your "well known" shopping cart software is
slightly incompatible with your web hosting service. You can
possibly get around this by installing Crypt::SSLeay in your
web account.

But even that won't work if the payment service provider
absolutely requires that port 443 be open on the web host, and
it's not.

Maybe next time you can buy the shopping cart software, web
hosting and payment service as part of a package of guaranteed
compatible services and software.

Re: SSL protocol via custom module?

wrote in message
..
..

The shopping cart scripts appear to post the information by calling a
function
::HTTPS_SendAndReceive('www.xxxx.com', 443,
'/xxx.dll/apc/apc', $sPostedData, 'POST', $::TRUE, $ssl_socket);

Seems a reasonable guess that this is going to send and receive via port
443. If that port is being blocked by the ISP, then it also seems reasonable
to assume that command will not work.

In which case you need to get the ISP to either unblock that port, or have
the script specifiy a different (unblocked) port.

Cheers,
Rob

Re: SSL protocol via custom module?

On Fri, 04 Aug 2006 10:28:16 -0700, petesouthwest wrote:
> I have bought a 'well known' shopping cart program which I'm trying
> to use with a 'well known' payment service provider.
> [...]
> The payment service provider says that in order for the process to
> work, the server hosting my shopping cart must have SSL support. This
> is apparently as the process uses a POST to send a simple
> acknowledgement back to an HTTPS website, for handshaking purposes. The
> payment service provider says that as the hosts system is a Linux box
> it requires crypt::SSLeay and port 443 open.

Your problem appears to be that you're confused by not understanding the
technology sufficiently and dealing with people who are using the terms
improperly so that when you talk to someone else, they think you mean
something different from what you intend.

Is your shopping cart program designed and documented to work with this
payment service provider? You're not trying to integrate a shopping cart
from one vendor with a payment service module from another, are you? That
would require hacking of some degree, possibly considerable.

Here's how the process happens: a user on their browser makes a
HTTP connection to your web server to buy something. At least at the
point where they supply credit card data, *that* connection needs to be
secured via SSL so that no one snoops the information. So your site host
needs to open port 443 and the URL the CC data is posted to needs to use
the https scheme. There is another way that this is sometimes done where
your program *redirects* the user to a secure site run by the payment
service provider before they enter CC data, but it sounds like you're not
doing that.

Your shopping cart program then sends the CC data off to the payment
service provider to be booked. That transaction is also done via HTTP and
needs to be secured via SSL again. Your program is now acting as a web
client. Your site host does *not* need to open port 443 for *this*
operation, because you're connecting to port 443 on the *remote* host.
It's conceivable that your host blocks outgoing connections such as that
made by your program out of some misplaced sense of security. I would
dump anyone that did that.

> However after a week of pushing the cart company they now say that that
> SSL support is not required as their own module, an sc.pm file in
> stored in the cgi-bin uploaded during the cart upload provides the SSL
> support.
>
> Searching for their scripts for lines like 'new HTTP::Request
> "POST","url"; certainly draws a blank.
>
> The shopping cart scripts appear to post the information by calling a
> function
> ::HTTPS_SendAndReceive('www.xxxx.com', 443,
> '/xxx.dll/apc/apc', $sPostedData, 'POST', $::TRUE, $ssl_socket);
>

A simple search on the above shows you asking the same question (with more
detail) at http://community.actinic.com/showthread.php?p=117075 . The
answer to your last query there is that the code uses Net::SSL to make the
secure connection. Net::SSL comes with Crypt::SSLeay, therefore you need
to install the Crypt::SSLeay distribution. See
http://search.cpan.org/~chamas/Crypt-SSLeay-0.51/ .

--
Peter Scott
http://www.perlmedic.com/
http://www.perldebugged.com/

Re: SSL protocol via custom module?

Why did you BUY a cart when you could just use a free one (open source)
that supports any payment system and would provide you with plenty of
support in the community??

Re: SSL protocol via custom module?

Peter Scott wrote:

> Your problem appears to be that you're confused by not understanding the
> technology sufficiently and dealing with people who are using the terms
> improperly so that when you talk to someone else, they think you mean
> something different from what you intend.
>
> Is your shopping cart program designed and documented to work with this
> payment service provider? You're not trying to integrate a shopping cart
> from one vendor with a payment service module from another, are you? That
> would require hacking of some degree, possibly considerable.

> Peter Scott
> http://www.perlmedic.com/
> http://www.perldebugged.com/

You have hit my problem in one!

The shopping cart website and documentation state clearly that it
'integrates seemlessly' with the payement service provider. The payment
service provider's website states the same thing.

We told our host company the 'published' requirements of the shoping
cart company and the service provider ie Perl ver 5 or later, MD5
recommended, and our host said our package included that.

No troubleshooting information regarding this problem is available in
the shopping cart company's documentation, and the answers from their
support team show they dont always understand the process involved. The
payment service provider has been very helpfull, but they are not the
ones selling the product and thus i believe their responcibility is
limited. They do have test scripts which have highlighted that SSL
suport is required for the process to work. However, when asked, the
cart company's technical department started by saying the Payement
service provider was wrong and SSL support was not required, but after
4 days of me quoting parts of their code, and asking how it would work
without SSL suport they finaly said, SSL support was needed but was
provided by one of their own modules.

The shopping cart people have yet to suggest a reason for the problem.

We paid for this package as it states in all their documantation that
the shoping cart would integrate with our accounts package and payment
service provider 'out of the box' with no customisation required. I'm
not aware of any open source cart that would offer that.

With hind-sight and searching thier forum for the appropriate technical
terms, we have found the problem was first highlighted and unsolved in
2004

many thanks