5. SSL IN NON-BROWSER SOFTWARE
We analyze a representative sample of non-browser software applications and libraries that use SSL for secure Internet connections. Some programs, such as instant messenger clients and simple mobile banking apps, are fairly straightforward in their use of
SSL. Others, especially middleware libraries, use SSL as part of a
multi-layer software stack. Many of the programs we analyze transmit extremely sensitive data—private files of individual users in the
case of cloud clients, financial information of customers in the case
of merchant SDKs, developer account credentials in the case of
mobile advertising software—over potentially insecure public networks, thus it is absolutely critical that they use SSL correctly.
Cloud client APIs. As cloud-computing platforms such as Amazon EC2 grow in popularity, their operators supply client SDKs
through which third-party software can transmit user data to cloudbased storage, manage cloud-based computation (e.g., start and terminate virtual instances), and access other cloud services. For example, Amazon provides EC2 API tools in Java, PHP, Python, and
Perl. Apache Libcloud is an example of an independent library for
accessing multiple cloud providers.
Merchant payment SDKs. Operators of e-commerce websites often rely on third parties such as PayPal and Amazon Flexible Payments Service (FPS) to process their customers’ payments. Payment processors provide merchant SDKs (software development
kits) in a variety of languages. These libraries are designed to be
integrated into the back end of e-commerce websites. Merchant
software uses them to transmit customers’ payment details and/or
receive notifications when payments are made by customers.
An online store typically has two options for payment processing. The first option is to have the customer enter payment details
directly into the payment processor’s website. When the customer
checks out, the merchant’s website redirects her browser to PayPal
or Amazon, where the customer enters her name, credit or debit
card number, etc. The merchant never sees these details. Once the
payment is complete, the payment processor redirects the customer
back to the merchant’s website and notifies the merchant.
The merchant’s site runs a daemon listening for IPN (InstantPayment Notification) calls from the payment processor. Upon receiving a notification, the merchant is advised to verify that the call indeed originated from the processor (some merchants skip this step,
opening the door to “shop-for-free” attacks [23]). The merchant
then completes the transaction with the customer.