SSL protocol via custom module?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View


I have bought a80=98well known=E2=80=99 shopping cart program which I'=
m trying
to use with a80=98well known=E2=80=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 correct81=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 file in
stored in the cgi-bin uploaded during the cart upload provides the SSL

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

The shopping cart scripts appear to post the information by calling a
::HTTPS_SendAndReceive('', 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-> = instantiateMD5Object();
    # Construct the SHA1 object
    $Self-> = instantiateSHA1Object();
    # Some more initialisation

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/ like my host says it is
4)    Would all of the above negate the need for a module like

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.



Re: SSL protocol via custom module? wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

    Whose Perl script?

Quoted text here. Click to load it

    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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

    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.

Quoted text here. Click to load it

    No - MD5 is not a secure transport layer.

Quoted text here. Click to load it

    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, wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it


Most likely.

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

Quoted text here. Click to load it

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?


The shopping cart scripts appear to post the information by calling a
::HTTPS_SendAndReceive('', 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.


Re: SSL protocol via custom module?

On Fri, 04 Aug 2006 10:28:16 -0700, petesouthwest wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

A simple search on the above shows you asking the same question (with more
detail) at .  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 .

Peter Scott / /

Re: SSL protocol via custom module?

Peter Scott wrote:

Quoted text here. Click to load it

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

many thanks

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??

Site Timeline