sagepay TLS 1.2 update - opayo

Sagepay and all other doing transition from TLS 1.1 to 1.2 as a security update.
Sagepay has three integration methods.
Sage Pay Form
Sage Pay Server
Sage Pay Direct
As per sagepay email, web servers integrating "Sage Pay Server" or "Sage Pay Direct" need to confirm their web server supports TLS 1.2
For "Sage Pay Form", web servers not required to support TLS 1.2 as credit information captured on sagepay itself?
Sagepay should mention it somewhere.

SagePay Support Response:
If you use “Sage Pay Server” or “Sage Pay Direct” Integration to process ecommerce payments you will need to ensure your systems use TLS 1.2 before the deadline dates below.
Sage form does not require any updates.
When your server connects to a Sage Pay server to process a transaction, Transport Layer Security (TLS) protocol encrypts the communications to keep them safe from malicious activity.
You or your developer can find out which TLS protocol your website uses by
entering your domain on a website like www.ssllabs.com

If you are using SagePay for checkout from your web site and your site is coded with ASP.NET then just add the following code prior to making the call to Sage
// Create a request using a URL that can receive a post.
// Set protocol to TLS1.2
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
// Send the request
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(PayAction);

If your application is returning the error [The request was aborted: Could not create SSL/TLS secure channel], then you are possibly having the same issue as me.
This fix worked for me on Windows Server 2016, .net framework 4.5.2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
DWORD: Enabled
Value: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
DWORD: DisabledByDefault
VALUE: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
DWORD: Enabled
Value: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
DWORD: DisabledByDefault
VALUE: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
DWORD: Enabled
Value: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
DWORD: DisabledByDefault
VALUE: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
DWORD: Enabled
Value: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
DWORD: DisabledByDefault
VALUE: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
DWORD: Enabled
Value: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
DWORD: DisabledByDefault
VALUE: 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
DWORD: Enabled
Value: 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
DWORD: DisabledByDefault
VALUE: 1
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NetFramework\v4.0.30319
DWORD: SchUseStrongCrypto
VALUE: 1
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NetFramework\v4.0.30319
DWORD: SchUseStrongCrypto
VALUE: 1
Server restart is required.

Related

enabling HTTP 2 to secure against Request smuggling - IIS 7 and cold-fusion 2016

i have a coldfusion 2016 website running over IIS 7.0 . I want to ensure it is not susceptible to HTTP smuggling
i want to enable HTTP 2 to resolve this issue ..
Question : what all places i have to make changes to enable HTTP 2 ?
IIS
is there any setting in coldfusion 2016 process as well to enable HTTP 2?
below is some reference material on what HTTP smuggling is :
http://projects.webappsec.org/w/page/13246928/HTTP%20Request%20Smuggling
https://www.youtube.com/watch?v=PFllH0QccCs
Thanks

Jmeter with www-Authenticate Basicrealm="Secured Area"

I am using Jmeter for performance testing and as i try to replay the request I am getting the following response header
I am using HTTP Authorization Manager with the following info
base url - example.com
username - username
password - kind
domain - example.com:80
Realm -
Mech - Basic_digest
Body size in bytes: 0
Sample Count: 1
Error Count: 1
Response code: 401
Response message: Unauthorized
Response headers:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="Secured Area"
Server: BigIP
Connection: Keep-Alive
Content-Length: 0
anythoughts on what I should try different
Thanks
Assumption 1: you're providing realm Mech and server expects it to be Secured Area.
As per RFC 1945
The realm attribute (case-insensitive) is required for all
authentication schemes which issue a challenge. The realm value
(case-sensitive), in combination with the canonical root URL of the
server being accessed, defines the protection space. These realms
allow the protected resources on a server to be partitioned into a
set of protection spaces, each with its own authentication scheme
and/or authorization database. The realm value is a string, generally
assigned by the origin server, which may have additional semantics
specific to the authentication scheme.
So try changing "Realm" in to "Secured Area" in HTTP Authorization Manager to see how it goes.
Assumption 2: authentication is not "Basic". See Windows Authentication with Apache JMeter guide for details on how to bypass NTLM and Kerberos authentication challenges.
3/13 - I did resolve this by adding a authorization header and removing the authorization manager all together.

SAP Gateway CSRF Protection only works over HTTPS, not over HTTP

Today I faced the problem that (suddenly) the SAP Gateway stopped acceppting CSRF tokens issued by himself.
Checked the network trace, everything is fine. The Client gets a token using GET Method and the HTTP Header
X-CSRF-Token: Fetch
receiving one, followed by an immediate POST request using the received Token and getting a 403 Forbidden status with response Body "CSRF Token could not be verified" (or similar)
By default, the CSRF Protection is only enabled over HTTPS in SAP Netweaver Gateway. How to enable CSRF over HTTP (and why not to do so) is described in the following SAP Note:
1896961 - HTTP/HTTPS Configuration for SAP NetWeaver Gateway
The important bit of the Note:
... set the instance profile parameter login/ticket_only_by_https to 0...

Can't see Https traffic in fiddler - it only shows "tunnel" - https decryption enabled

I have a ASP.NET MVC based web site which runs on http.
From the above web site I'm making a https call to a web API
Configured fiddler as a proxy and trying to monitor the traffic using Fiddler Web Debugger (ver 4.4.8.4)
I only see "tunnel to" requests to the https web api sent from the MVC web application. Why am I not able to see other https traffic including request/response headers/body?
I have enabled decrypting https setting in fiddler. I have followed this link:
http://fiddlerbook.com/Fiddler/help/faq.asp
Is there anything else I can check?
Let's step back a bit:
Is the HTTPS request to the web API being made from JavaScript on the client, or from ASP.NET code on the server?
Did the request actually succeed?
What, if anything, do you see in Fiddler's LOG tab?

Help getting Net::HTTP working with authentication in Ruby

I'm trying to get a Ruby script to download a file off a server, but I'm getting a 401.2 from IIS:
You do not have permission to view
this directory or page using the
credentials that you supplied because
your Web browser is sending a
WWW-Authenticate header field that the
Web server is not configured to
accept.
I've checked that basic auth is enabled. Is there something special about how Ruby handles basic auth? Is there a way for me to see what the server actually gets and what the headers say is acceptable?
This is my code:
Net::HTTP.start(url, port) {|http|
req = Net::HTTP::Get.new('/file.txt')
req.basic_auth 'username', 'password'
response = http.request(req)
puts response.body
}
Snippet from the Microsoft website
HTTP 401.2: Denied by server configuration
Description
The client browser and IIS could not agree on an authentication protocol.
Common reasons
* No authentication protocol (including anonymous) is selected in IIS. At least one authentication type must be selected. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
253667 (http://support.microsoft.com/kb/253667/ ) Error message: HTTP 401.2 - Unauthorized: Logon failed due to server configuration with no authentication
* Only Integrated authentication is enabled, and an older, non-Internet Explorer client browser tries to access the site. This happens because the client browser cannot perform Integrated authentication. To resolve this problem, use one of the following methods:
o Configure IIS to accept Basic authentication. This should only occur over SSL for security purposes.
o Use a client browser that can perform Integrated authentication. Internet Explorer and new versions of Netscape Navigator and Mozilla Firefox can perform Integrated authentication.
* Integrated authentication is through a proxy. This happens because the proxy doesn't maintain the NTLM-authenticated connection and thus sends an anonymous request from the client to the server. Options to resolve this problem are as follows:
o Configure IIS to accept Basic authentication. This should only occur over SSL for security purposes.
o Don't use a proxy.
You should also try to look at ruby-httpclient - Simple HTTPClient library for Ruby which can use NTLM auth.

Resources