How Safe Are Your Business’ Online Payments?: E-Commerce Sites and Protected Payment Gateways
October 21, 2015 by
CA Security Council
Encryption
Google
SSL/TLS
This blog was originally posted on staysafeonline.org on June 29, 2015.
Online payments can be made in a variety of ways, but majority of the online financial transactions are done through secured payment gateways. Secure payment gateways, as the name suggests, are application service providers for ecommerce websites that authorize various financial transactions taking place on online stores for ensuring safety for both the retailers and the online buyers. The key goal of payment gateways is to secure personal information like cconsumers’ credit card numbers by encrypting their personal and confidential information. Learn more about what these gateways are and how they help protect your online transactions.
What Are “Application Reputation” and “Publisher Reputation”?
August 27, 2015 by
Ben Wilson
Code Signing
Malware
Microsoft
As one dog says to the other in Peter Steiner’s classic New Yorker cartoon– “On the Internet, nobody knows you’re a dog.”
Software downloaded from the Internet is similar to people on the Internet–it is hard to tell which ones are dogs–without help, which is what “application reputation” technology provides. “Application reputation” and “publisher reputation” are methods employed by Microsoft’s SmartScreen and other systems to distinguish good software from bad software as it is downloaded from the Internet. Reputation works similar to the way that we develop trust in other people– we study them over the course of multiple encounters or, if we don’t have prior experience with them, then we rely on others for information about reputation.
OpenSSL High Severity Vulnerability
July 10, 2015 by
Bruce Morton
(Entrust)
Attack
DTLS
Google
MITM
OpenSSL
SSL/TLS
Vulnerability
OpenSSL has announced a high severity vulnerability, CVE-2015-1793 which will require an upgrade to some OpenSSL installations.
The vulnerability was discovered by Google personnel Adam Langley and David Benjamin on June 24, 2015. Google has been working on an alternative to OpenSSL called BoringSSL. This has allowed Google to reduce vulnerabilities in their installations, but is also a benefit to OpenSSL as issues have been reported. Note that BoringSSL is not impacted.
New Directions for Elliptic Curve Cryptography in Internet Protocols
June 24, 2015 by
Rick Andrews
ECC
ECDSA
IETF
NIST
RSA
SSL/TLS
Last week I attended and presented at the National Institute of Standards and Technology (NIST) Workshop on Elliptic Curve Cryptography Standards. In NIST’s words, “The workshop is to provide a venue to engage the crypto community, including academia, industry, and government users to discuss possible approaches to promote the adoption of secure, interoperable and efficient elliptic curve mechanisms.”
We began by discussing the reasons for holding this workshop. Speakers acknowledged that although there are no known issues with the current set of NIST curves, in some circles they are widely distrusted. In addition, they are almost 15 years old, not particularly resistant to side-channel attacks, and don’t perform as well as newer curves. For these reasons, many people feel that NIST should standardize on one or more new curves.
The Insecurity of Mobile Applications
June 11, 2015 by
Rick Andrews
Android
Attack
MITM
OpenSSL
SSL/TLS
Vulnerability
Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see these studies). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three (#3) in its top 10 list of mobile security problems of 2014. Apps that don’t use SSL/TLS are particularly vulnerable, given the ease of reading and modifying unsecured traffic at Wi-Fi hot spots, for example. But even apps that use SSL/TLS must be careful to implement proper checking to ensure that attackers can’t exploit weaknesses.
Facebook Will Stop Supporting SHA-1 in October
June 8, 2015 by
Ben Wilson
Announcement
SSL/TLS
On June 2, 2015, Facebook announced that it would stop supporting Facebook-connected apps that were signed with SHA-1, as of October 1, 2015.
“These changes are part of a broader shift in how browsers and web sites encrypt traffic to protect the contents of online communications. Typically, web browsers use a hash function to create a unique fingerprint for a chunk of data or a message. This fingerprint is then digitally signed to prove that a message has not been altered or tampered with when passing through the various servers and systems between your computer and Facebook’s servers.” [https://developers.facebook.com/blog/post/2015/06/02/SHA-2-Updates-Needed/]
Server Name Indication and Fewer IP Addresses
June 2, 2015 by Bruce Morton (Entrust) Attack Chrome MITM SSL/TLSYou have a dilemma. You want to continue to deploy your web service but are running out of IPv4 addresses. You consider deploying multiple virtual servers that will use the same IP address. However, your thought is that you can only have one SSL certificate per IP address. How will you make your service secure?
Server Name Indication (SNI) is an extension to the SSL/TLS protocol that allows the browser or client software to indicate which hostname it is attempting to connect. SNI is defined in RFC 6066.
Practical Steps to Counter the Logjam Attack
May 26, 2015 by Kirk Hall (Entrust) Apple Attack Encryption Google MITM SSL/TLS VulnerabilityAnother flaw has been found in the basic encryption algorithms that secure the Internet. This flaw, named the Logjam attack by its discoverers (researchers from various universities and companies), allows an attacker that can carry out man-in-the-middle (MitM) attacks to weaken the encryption used in secure connections (such as HTTPS, SSH, and VPNs). In theory, this means that an attacker (with sufficient resources) can break the encryption and read the “secure” traffic.
Why You Should Get Familiar With TLS If You Accept Credit Cards
April 28, 2015 by Billy VanCannon Encryption PDF SSL/TLS VulnerabilityThe group that manages the Payment Card Industry Data Security Standard quietly announced in February that an imminent update was coming to its payment card and application requirements related to the use of the SSL encryption protocol. Since then, there has been growing concern among merchants about what the changes mean to them.
The confusion among retailers generally can be boiled down to two questions:
- What will the new updates require me to do?
- What happens to my TSL/SSL certificates?
First let’s explain what’s going on: On Feb. 13, the PCI Security Standards Council informed its assessor community that SSL (Secure Sockets Layer) – a protocol designed to ensure that data provided between a web server and a web browser, such as credit card information, remains secure – is no longer an acceptable way to provide “strong cryptography.” This is due to a number of known fundamental vulnerabilities – some of which, such as Heartbleed, we have documented here, here and here – that essentially make SSL, as an encryption mechanism, obsolete.
HTTP/2 Is Speedy and Secure
April 20, 2015 by Wayne Thayer Announcement Chrome Firefox Forward Secrecy Google HSTS IETF Microsoft Mozilla SSL/TLS VulnerabilitySince we last wrote about SSL/TLS performance, there has been a lot of activity in the IETF HTTP Working Group, resulting in the February announcement that the next version of HTTP has been approved. This is big news because it means that major SSL/TLS performance improvements are on the way.
Background
When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616. Over the past 15 years, HTTP/1.1 has served us well and many tweaks have been discovered to make the most of it. However, in that time the web has transformed into a platform for interactive content and applications. Today, browsers load much more data from many more sources to build the typical web page.
