Download Organizations That Use TLS/SSL

TLS is a successor to Secure Sockets Layer protocol. TLS provides secure
communications on the Internet for such things as e-mail, Internet faxing, and other data
transfers. There are slight differences between SSL 3.0 and TLS 1.0, but the protocol
remains substantially the same. It is good idea to keep in mind that TLS resides on the
Application Layer of the OSI model. This will save you a lot of frustrations while
debugging and troubleshooting encryption problems related to TLS.
The TLS Handshake Protocol allows the server and client to authenticate each other
and to negotiate an encryption algorithm and cryptographic keys before data is
exchanged. In a typical scenario, only the server is authenticated and its identity is
ensured while the client remains unauthenticated. The mutual authentication of the
servers requires public key deployment to clients. When a server and client
communicate, TLS protocol ensures that no third party may eavesdrop, tamper with any
message, and message forgery.
With all the recent stories about security breaches, you may be wondering what you can do to help secure your
nonprofit or library's data and communications. Transport Layer Security (TLS) is a protocol (or set of guidelines) that
can help you do this. If your organization stores or processes payment or health-care data, or if it collects confidential
information in general, security safeguards such as TLS or Secure Sockets Layer (SSL) might be not only a good
idea but also legally mandated.
Below, we'll show you how TLS/SSL works, when you should use it, and how you can implement it at your
organization.
What is TLS/SSL?
TLS is the successor to SSL, which is an older protocol. The differences between TLS and SSL are minor and very
technical. For purposes of this discussion the protocols are basically identical, so we will lump them together as
TLS/SSL.
TLS/SSL can be used to create a secure environment for web browsing, emailing, or other client-server applications.
For example, TLS can be used to create a secure connection between your organization's donation web page and a
donor's web browser. The donor's financial or other personal information is encrypted in such a way that only you and
the donor can access and use it.
TLS/SSL encryption requires the use of a digital certificate, which contains identity information about the certificate
owner as well as a public key, used for encrypting communications. These certificates are installed on a server —
typically a web server if the intention is to create a secure web environment, although they can also be installed on
mail or other servers for encrypting other client-server communications.
Microsoft has a more detailed explanation of how TLS/SSL works.
Securing a Web Server with TLS/SSL
This is probably the most common use of TLS/SSL. If used with a web server, TLS/SSL can encrypt online
transactions and confidential data relayed between a user's web browser and a website. A secured web server can
be identified by a padlock symbol at the bottom of the browser window or in the address bar, as well as by a URL that
begins with "https" rather than "http."
Securing a Mail Server, Database Server, or Directory
Server with TLS/SSL
TLS/SSL can be used with mail servers to encrypt email messages. An email that was sent with TLS/SSL encryption
may display a ribbon or other icon in the recipient's email client. TLS/SSL can similarly be used with database and
directory servers to encrypt server queries.
Securing a Virtual Private Network (VPN) with
TLS/SSL
TLS/SSL can be used to encrypt the connection between a remote user's device and the network being accessed.
Does My Organization Need to Use TLS/SSL?
Whether you need to use TLS/SSL depends on your organization's activities. For organizations involved in health
services or payment processing, using a security protocol such as TLS/SSL to encrypt network communications may
be a federal or commercial requirement. For other organizations, using TLS/SSL might simply be a good idea.
Organizations Involved in Health Services
For organizations involved in health services, using security safeguards such as TLS/SSL may be a federal
requirement. Any organization that transmits electronic billing information to any health insurance provider, Medicare,
or Medicaid, is covered by the Health Insurance Portability and Accountability Act (HIPAA) and must meet certain
security standards. Additionally, any organization that stores or transmits user login or patient information may need
to be compliant with the HIPAA Security Standard, even if it is not technically a covered entity. It is important to
remember that security protocols such as TLS/SSL can help an organization become HIPAA compliant, but they do
not provide compliance on their own. For more information on HIPAA and finding out whether your organization
needs to comply with its requirements, see Idealware's In Search of HIPAA-Compliant Software and visit the
official HIPAA website at the Department of Health and Human Services.
Organizations that Store or Process Payment
Information
For organizations that store or process payment information, such as donor credit card numbers, implementing
TLS/SSL may be a requirement of the Payment Card Industry Data Security Standard (PCI DSS). This standard was
created by the PCI Security Standards Council, a group of several major payment card brands, to protect cardholder
data. Organizations may be required to comply with the PCI DSS by their acquiring bank or payment processor. You
may have heard the term PCI-compliant in reference to certain websites, meaning that these sites have proven their
compliance with these standards. As with the HIPAA standards noted above, remember that security protocols such
as TLS/SSL can help an organization become PCI compliant, but they do not provide compliance on their own. For
more information on PCI DSS and compliance, visit the PCI SSC website.
Other Organizations
If your organization stores confidential user information but does not transmit health or payment information, you still
might want to implement security safeguards like TLS/SSL. First-time visitors will appreciate knowing that their
personal information (like address and phone numbers) is secure when submitting it to your website. Organizations
associated with human rights and justice could benefit from encryption by protecting the information, and even the
identities, of the people they serve. The use of TLS/SSL can also provide secure connections for organizations
accessing their networks remotely. Though these safeguards would not be required by the federal government or a
commercial entity, they could help to ensure that an organization's mission is not compromised by security breaches.
How Can My Organization Use TLS/SSL?
Most uses of TLS or SSL require a digital certificate from a certification authority or certificate authority (CA), a trusted
authority that can attest to the identity of the certificate owner. Organizations will also need a system or network
administrator who is familiar with whichever client-server applications need to be secured to enable TLS/SSL
encryption.
If an organization purchases a certificate from a trusted CA, that certificate will contain the digital signature of the
certification authority, attesting to the certificate's validity. Organizations can also create their own certificates, known
as self-signed certificates, although these will not be inherently trusted by a web browser if installed on a web server
and will usually display a security warning for any user who visits a website with a self-signed certificate.
Certificates are usually issued for a one-year period, and different security features may be available depending on
the vendor. Most of these features are targeted at organizations that will install these certificates on web
servers. Extended Validation (EV) certifies that the certificate owner meets the highest standard of identity validation
criteria established by the Certificate Authority Browser Forum — a voluntary organization of certification authorities
— and vendors of Internet browser software. EV certificates also enhance security visibility by displaying the
organization's name in green in the address bar as well as displaying the name of the issuing certification authority.
There are several commercial certification authorities, including VeriSign, Comodo, GeoTrust, and GoDaddy. Visit
each of those organization's websites to compare prices or request a certificate.
Organizations That Use TLS/SSL
Organizations of various sizes have made use of TLS/SSL for many of the purposes described here. A good example
is the National Cristina Foundation, a nonprofit organization that provides computers and other technology to people
with disabilities, students at risk, and the economically disadvantaged. Their website uses SSL to secure an online
form that is filled out by parties who wish to donate computers or other items to the organization. The organization
also uses SSL to encrypt its online grant application used by prospective recipients to obtain the technology they
need.
Another nonprofit organization, Blood Centers of the Pacific, uses SSL encryption on its Blood Heroes blood donation
website to allow donors to securely enter their information, make appointments, and view health information about
their blood. And of course, TechSoup uses SSL certificates to keep its own members' information secure. The
TechSoup login page uses this encryption, as does the entire check-out process on TechSoup's Get Products
donation site.
Conclusion
No single security measure will fully protect your organization from unauthorized data breaches, but implementing
security protocols like TLS/SSL can reduce the chance of such threats. If you are not obligated by law or commercial
edict to implement a protocol like TLS/SSL but think it might be a good idea, you should find out whether you have
the technical staff and resources to do so. Staff and constituents who are worried about their information's safety will
likely appreciate these safeguards. When it comes to data security, erring on the side of caution is typically a prudent
choice.
Short for Transport Layer Security, a protocol that guarantees privacy and data integrity
between client/serverapplicationscommunicating over the Internet.


The TLS protocol is made up of two layers:
The TLS Record Protocol -- layered on top of a reliable transport protocol, such as TCP, it ensures that the
connection is private by using symmetric data encryption and it ensures that the connection is reliable. The TLS
Record Protocol also is used forencapsulationof higher-level protocols, such as the TLS Handshake Protocol.
The TLS Handshake Protocol -- allows authentication between the server and client and the negotiation of an
encryption algorithmand cryptographic keys before the application protocol transmits or receives any data.
TLS is application protocol-independent. Higher-level protocols can layer on top of the TLS protocoltransparently.
Insufficient Transport Layer Protection
Insufficient transport layer protection allows communication to be exposed to untrusted third-parties,
providing an attack vector to compromise a web application and/or steal sensitive information. Websites
typically use Secure Sockets Layer / Transport Layer Security (SSL/TLS) to provide encryption at the
transport layer [1]. However, unless the website is configured to use SSL/TLS and configured to use
SSL/TLS properly, the website may be vulnerable to traffic interception and modification.
Lack of Transport Layer Encryption
When the transport layer is not encrypted, all communication between the website and client is sent in
clear-text which leaves it open to interception, injection and redirection (also known as a man-in-themiddle/MITM attack). An attacker may passively intercept the communication, giving them access to any
sensitive data that is being transmitted such as usernames and passwords. An attacker may also actively
inject/remove content from the communication, allowing the attacker to forge and omit information,
inject malicious scripting, or cause the client to access remote untrusted content. An attacker may also
redirect the communication in such a way that the website and client are no longer communicating with
each other, but instead are unknowingly communicating with the attacker in the context of the other
trusted party.
Weak Cipher Support
Historically, high grade cryptography was restricted from export to outside the United States[2]. Because
of this, websites were configured to support weak cryptographic options for those clients that were
restricted to only using weak ciphers. Weak ciphers are vulnerable to attack because of the relative ease of
breaking them; less than two weeks on a typical home computer and a few seconds using dedicated
hardware[3].
Today, all modern browsers and websites use much stronger encryption, but some websites are still
configured to support outdated weak ciphers. Because of this, an attacker may be able to force the client
to downgrade to a weaker cipher when connecting to the website, allowing the attacker to break the
weak encryption. For this reason, the server should be configured to only accept strong ciphers and not
provide service to any client that requests using a weaker cipher. In addition, some websites are
misconfigured to choose a weaker cipher even when the client will support a much stronger one. OWASP
offers a guide to testing for SSL/TLS issues, including weak cipher support and misconfiguration[4], and
there are other resources and tools [5][6] as well.
SCP (Secure Copy) for securing data transmissions with your trading partners. SCP creates an
encrypted tunnel using SSH between two computer systems and will protect against the following
attacks:





IP spoofing, where a remote host sends out packets which pretend to come from another,
trusted host
IP source routing, where a host can pretend that an IP packet comes from another, trusted
host.
DNS spoofing, where an attacker forges name server records
Interception of cleartext passwords and other data by intermediate hosts
Manipulation of data by attackers in control of intermediate hosts
GoAnywhere MFT provides SCP features to satisfy enterprise requirements.











Ability to authenticate using passwords or SSH keys
Get, Put, MGet commands
Transfer multiple files per connection using loops
Indicate the number of connection retry attempts and timeout values
Auto suffix and prefix file names with constants, timestamps or variables
Override file names and other properties at execution time using variables
Auto retry with user-defined connection timeouts and retry limits
Configurable port numbers
Support for Adaptive connections
Utilizes only strong NIST-certified encryption algorithms when in FIPS 140-2
Compliance mode
Generation of detailed logs (audit trails)
SSH Key Management
A comprehensive Key Manager is provided in GoAnywhere MFT to allow for the management of
SSH Keys. The Key Manager can be used to create SSH public and private keys, export keys and
view keys. These SSH Keys can be utilized within GoAnywhere MFT for automating SFTP
transmissions.
GoAnywhere MFT supports the following standards for SCP:
Protocol

SSH 2.0
Ciphers (Symmetric Encryption Algorithms)



Triple DES, key length of 192 bit
Blowfish, key length up to 448 bit
AES, key length up to 256 bit
MAC Algorithms




MAC-SHA1, key length of 160 bit, digest length of 160 bit
HMAC-SHA1-96, key length of 160 bit, digest length of 96 bit
HMAC-MD5, key length of 128 bit, digest length of 128 bit
HMAC-MD5-96, key length of 128 bit, digest length of 96 bit
Key Exchange Algorithms


Diffie-Hellman
MODP Groups 1, 2, 5 (1536-bit), 14 (2048-bit), 15 (3072-bit), 16 (4096-bit), 17 (6144-bit) and
18 (8192-bit).
SSH Private Keys


OpenSSH encoded keys
PEM (privacy enhanced message) encoded keys
SSH Public Keys

OpenSSH encoded keys
Definition - What does Secure Copy mean?
Secure copy (SCP) is a file transfer protocol, which helps in transferring computer files securely from
a local host to a remote host. It works on the Secure Shell (SSH) protocol technique.
The term secure copy refers to either the SCP protocol or the SCP program. The SCP protocol is a
file transfer network protocol, which supports encryption and authentication features. It is based on
the Berkeley Software Distribution (BSD) Remote Copy Protocol (RCP), which runs on port 22 using
the SSH Protocol.
Techopedia explains Secure Copy
SCP can be called more of a combination of RCP and SSH than a protocol because the file transfer
is performed using RCP and authentication and encryption are provided by the SSH Protocol. SCP
maintains the confidentiality of the data being transferred and protects the authenticity by blocking
packet sniffers from extracting valuable information from the data packets.
The SSH protocol supports the inclusion of basic attributes like permissions and timestamps for the
file to be uploaded. The inclusion of a date/timestamp attribute is not supported in common FTP.
The client provides the server with all the files to be uploaded. A request for downloading the files
and directories is sent by the client. The server provides the client with all the subdirectories and files
available for download. Since the download is controlled by the server, there are chances of security
risks when connected to a malicious server.
On the other hand, the SCP program implements the SCP protocol as a client or a service daemon.
The SCP server program and the SCP client are one and the same. A typical example of an SCP
program is the command line SCP program available with most of the SSH implementations.
Insufficient Transport Layer Protection Defined
Insufficient Transport Layer Protection is a security weakness caused by applications not taking any
measures to protect network traffic. During authentication applications may use SSL/TLS, but they
often fail to make use of it elsewhere in the application, thereby leaving data and session ID's
exposed. Exposed data and session ID's can be intercepted which means the application is
vulnerable to exploit.
As OWASP states, "Applications frequently fail to authenticate, encrypt, and protect the
confidentiality and integrity of sensitive network traffic. When they do, they sometimes support weak
algorithms, use expired or invalid certificates, or do not use them correctly."
Because many versions of SSL/TLS protocols are used widespread across much deployed
applications such as web browsing, electronic mail, Internet faxing, instant messaging, voice-over-IP
(VoIP) and many other applications that communicate over the internet, insufficient transport layer
protection is ninth on the OWASP Top 10 risks.
Key Concepts of Insufficient Transport Layer Protection
Anyone on the internet can monitor the network traffic of your users. Distinguishing If the application
is on the internet, who knows how your users access it. Don’t forget back end connections.
Explaining Insufficient Transport Layer Protection through Examples
Let's examine how Insufficient Transport Layer Protections cause damage by looking at one of the
most basic example of a CRLF attack: adding fake entries into log files. Suppose a vulnerable
application accepts unsanitized or improperly neutralized data and writes it to a system log file. An
attacker supplies the following input:
Hello, World
DATABASE ERROR: TABLE CORRUPTION
Because this error is fake, a sysadmin may waste a lot of time troubleshooting a non-existent error.
An attacker could use this type of Trojan to distract the admin while attacking the system somewhere
else.
Another way to illustrate how Insufficient Transport Layer Protections can cause severe harm is
through an application that accepts a file name as user input and then executes a relatively harmless
command on that file such as "ls –a ". If the application is vulnerable to Insufficient Transport Layer
Protection because of improperly neutralized or unsanitized data input, an attacker could provide the
following input:
fname
/bin/rm -rf /
This Insufficient Transport Layer Protection attack could wipe out the entire file system if the
application were running with root privileges on a linux/unix system!
Preventing Insufficient Transport Layer Protections
Fortunately, Insufficient Transport Layer Protections are easy to prevent. Always follow the rule of
never trusting user input. Sanitize and neutralize all user supplied data or properly encode output in
HTTP headers that would otherwise be visible to users in order to prevent the injection of CRLF
sequences and their consequences.