When going to any government or service portal (for example, EIS), the user may suddenly encounter the error “It is not possible to securely connect to this page. The site may be using outdated or weak TLS security settings." This problem is quite common and has been observed for several years among various categories of users. Let's look at the essence of this error and the options for solving it.
As you know, the security of user connections to network resources is ensured through the use of SSL/TSL - cryptographic protocols responsible for the secure transmission of data on the Internet. They use symmetric and asymmetric encryption, message authentication codes and other special features that allow you to maintain the confidentiality of your connection, preventing third parties from decrypting your session.
If, when connecting to a site, the browser detects that the resource uses incorrect SSL/TSL security protocol parameters, the user receives the above message, and access to the site may be blocked.
Quite often, the situation with the TLS protocol arises in the IE browser, a popular tool for working with special government portals associated with various forms of reporting. Working with such portals requires the presence of the Internet Explorer browser, and it is on it that the problem in question arises especially often.
The reasons for the error “The site may be using outdated or insecure TLS security settings” may be as follows:
How to fix the dysfunction: Weak TLS security settings are being used
The solution to the problem may be the methods described below. But before describing them, I recommend that you simply restart your PC - although trivial, this method often turns out to be quite effective.
If it doesn't help, then do the following:
Conclusion
The cause of the error “The site may be using outdated or unreliable security parameters of the TLS protocol” is quite often a local PC antivirus, which for certain reasons blocks access to the desired Internet portal. If a problematic situation arises, it is recommended that you first disable your antivirus to make sure that it is not causing the problem in question. If the error continues to recur, then I recommend moving on to implementing other tips described below to resolve the problem of unreliable TSL protocol security settings on your PC.
All our arguments are based on the fact that the operating system is Windows XP or later (Vista, 7 or 8), on which all the appropriate updates and patches are installed. Now there is one more condition: we are talking about the latest versions of browsers, and not “spherical Ognelis in a vacuum.”
So, we configure browsers to use the latest versions of the TLS protocol and not use its outdated versions and SSL at all. At least, as far as possible in theory.
And the theory tells us that although Internet Explorer supports TLS 1.1 and 1.2 already from version 8, under Windows XP and Vista we will not force it to do so. Click: Tools/Internet Options/Advanced and in the “Security” section we find: SSL 2.0, SSL 3.0, TLS 1.0... did you find anything else? Congratulations, you will have TLS 1.1/1.2! If they didn’t find it, you have Windows XP or Vista, and in Redmond they consider you retarded.
So, uncheck all SSL boxes, check all available TLS boxes. If only TLS 1.0 is available, then so be it; if more current versions are available, it is better to select only them, and uncheck TLS 1.0 (and not be surprised later that some sites do not open over HTTPS). Then click the “Apply” and “OK” buttons.
It’s easier with Opera - it gives us a real banquet of different protocol versions: Tools/General Settings/Advanced/Security/Security Protocol. What do we see? The whole set, from which we leave the checkboxes only for TLS 1.1 and TLS 1.2, after which we click the “Details” button and there we uncheck all the lines except those that start with “256 bit AES” - they are at the very end. At the beginning of the list there is a line “256 bit AES ( Anonymous DH/SHA-256), uncheck it too. Click “OK” and rejoice in security.
However, Opera has one strange property: if TLS 1.0 is enabled, then if it is necessary to establish a secure connection, it immediately uses this version of the protocol, regardless of whether the site supports more current ones. Like, why bother – everything is fine, everything is protected. When only TLS 1.1 and 1.2 are enabled, the more advanced version will be attempted first, and only if it is not supported by the site will the browser switch to version 1.1.
But the spherical Ognelis Firefox will not please us at all: Tools/Settings/Advanced/Encryption: all we can do is disable SSL, TLS is available only in version 1.0, there is nothing to do - we leave it with a checkmark.
However, the worst is learned by comparison: Chrome and Safari do not contain settings at all on which encryption protocol to use. As far as we know, Safari does not support TLS versions more current than 1.0 in versions for Windows OS, and since the release of new versions for this OS has been discontinued, it will not be.
Chrome, as far as we know, supports TLS 1.1, but, as in the case of Safari, we cannot refuse the use of SSL. There is no way to disable TLS 1.0 in Chrome. But with the actual use of TLS 1.1 there is a big question: it was first turned on, then turned off due to operational problems and, as far as one can judge, has not yet been turned back on. That is, there seems to be support, but it seems to be turned off, and there is no way for the user to turn it back on. The same story is with Firefox - it actually has support for TLS 1.1, but it is not yet available to the user.
Summary from the above multiletter. What are the general dangers of using outdated versions of encryption protocols? The fact that someone else will get into your secure connection to the site and gain access to all the information “there” and “there”. In practical terms, he will get full access to his email box, account in the client-bank system, etc.
It is unlikely that you will accidentally break into someone else's secure connection; we are only talking about malicious actions. If the likelihood of such actions is low, or the information transmitted over a secure connection is not particularly valuable, then you don’t have to bother and use browsers that only support TLS 1.0.
Otherwise, there is no choice: only Opera and only TLS 1.2 (TLS 1.1 is just an improvement on TLS 1.0, partially inheriting its security problems). However, our favorite sites may not support TLS 1.2 :(
Today, many people and organizations use Internet banking services. Banks periodically conduct security audits of their systems, issue instructions and recommendations for safe work with Internet banking, but users do not always know whether the connection to the Internet bank that they are used to using is well protected.
In this article we will evaluate the security of connections to online services of the TOP-50 Russian banks (by assets).
The security of users' connection to online banks is ensured by using SSL/TLS protocols. Currently, there are known “high-profile” SSL/TLS vulnerabilities, which have even been given names and/or logos (Beast, Poodle, Heartbleed, Freak, Logjam). Known SSL/TLS vulnerabilities, among other things, allow you to decrypt sessions, intercept and replace data transferred between the user and the server, which, for obvious reasons, is overlooked by most users.
Often the problem lies in the use of outdated and weak cryptographic algorithms at the current level of computing power, and in some cases the presence of unresolved vulnerabilities in the software used. All this jeopardizes the security of payments made by users in online banks.
SSL/TLS security level of Russian banks
To evaluate the security level of the SSL/TLS configuration on your servers, you can use the free SSL Server Test tool from Qualys SSL Labs. Using this tool, independent researcher Troy Hunt compiled a summary of the appropriate level of security of Australian banks.In the comments to Troy's article you can see links to similar tables for different countries: Lithuania, Denmark, Holland, Holland-2, Czech Republic, Great Britain.
I prepared a similar table (dated 05/22/15) for the TOP-50 banks of the Russian Federation.
In general, the situation is far from ideal. Among the banks in the top ten there are four grades of “F” and compared to other countries this is a poor indicator.
With the exception of Logjam, quite a lot of time has passed since the discovery of these vulnerabilities and protocol/crypto-algorithm problems, which at a minimum indicates that many banks do not periodically monitor the security of their web resources or carry out appropriate compensatory measures.
Each web resource is assigned an “SSL Server Test” rating on a scale from A to F. Plus and green means there is no corresponding vulnerability/problem. Minus and red indicate the opposite. Some web resources could not be checked for the reasons indicated in the table.
Main conclusions
- Some banks still use insecure Diffie-Hellman key exchange parameters with key lengths of 512 and 768 bits, which automatically reduced their overall score to an "F" (this case also occurs in the top ten). Vulnerable resources are marked with minuses in the “DH” column.
- Some banks are vulnerable to FREAK attacks, which reduced their overall rating to “F”. Using this vulnerability, attackers can force the client browser to use weak cryptography from the “export” RSA cipher suite. Resources vulnerable to attack are marked with minuses in the “Freak” column.
- A considerable part of web resources have a POODLE vulnerability, which reduced their overall rating to “F”. Using this vulnerability, attackers can gain access to encrypted information transmitted between the client and server. Basically, these are insecure SSL3 protocol vulnerabilities and can be fixed by disabling SSL3 protocol on web servers. In two cases, the protocol vulnerable to POODLE is TLS and a patch is required to fix the vulnerability. Resources vulnerable to attack are marked with minuses in the “POODLE” column.
- Several banks still use the insecure SSL2 protocol, which has lowered their overall rating to an "F". The SSL2 protocol uses an insecure MD5 cryptographic hash function and weak ciphers. MITM attacks are possible due to the lack of SSL verification. In addition, SSL2 also uses the TCP FIN flag to close the session, which can be spoofed, leaving the user unaware if the data transfer is complete. Resources that support the SSL2 protocol are marked with minuses in the “SSL2” column.
- A significant portion of web resources have the Logjam vulnerability, which was discovered quite recently. The presence of the vulnerability reduced the overall rating to "B". Like the FREAK vulnerability, Logjam allows an attacker to force the client browser to use weak DH cryptography with 512-bit keys. Resources vulnerable to attack are marked with minuses in the “Logjam” column.
- A significant portion of banks still use the outdated and insecure SSL3 protocol, which has reduced their overall score to a “B”. Resources that support the SSL3 protocol are marked with minuses in the “SSL3” column.
- Some websites do not support the latest and most secure version of the TLS 1.2 protocol, which lowers their overall rating to a B. Resources that do not support the TLS 1.2 protocol are marked with minuses in the “TLS1.2” column.
- Most banks still use RC4 ciphers, which has lowered their overall rating to a "B". The RC4 vulnerability is due to the insufficient randomness of the bit stream used to scramble the message, allowing the intercepted data to be decrypted. Resources that support the RC4 cipher are marked with minuses in the “RC4” column.
- The vast majority of banks still use the SHA-1 hashing algorithm, which is considered weak and insecure. Already, web browsers assign different statuses to connections with SHA-1 (“secure but buggy,” “insecure,” “untrusted”). Ignoring the current rejection of SHA-1, banks are teaching their users not to pay attention to such browser statuses and messages. The use of SHA-1 had virtually no effect on the overall score and is marked with minuses in the “SHA-1” column.
- The overwhelming majority of banks have not implemented or partially implemented the security setting of key agreement protocols - Forward Secrecy. When using Forward Secrecy, session keys will not be compromised if the private key is compromised. Resources that do not use Forward Secrecy for most modern browsers are marked with minuses in the “FS” column.
- It is worth noting that the Heartbleed vulnerability was fortunately not found on any of the tested web resources.
- Disable support for insecure protocols SSL2, SSL3.
- Enable support for the most advanced TLS 1.2 protocol.
- Stop using SHA-1 certificates.
- Stop using the RC4 cipher.
- Set up Forward Secrecy and make sure the feature works for most modern browsers.
- Fix the Poodle vulnerability by disabling the SSL3 protocol, or by installing a patch for the TLS protocol vulnerability.
- Fix the Freak vulnerability by disabling support for exporting cipher suites.
- Address the Logjam vulnerability by disabling support for exporting cipher suites and generating a unique 2048-bit Diffie-Hellman group.
Based on industry guidelines for security and data integrity, Salesforce requires that the current encryption protocol be updated to TLS 1.2 by September 2019. Around this time, the TLS 1.1 encryption protocol will begin to turn off. To avoid instability of the production environment instance, the recommended actions should be completed before this date. This article contains all the available information about disabling the TLS 1.1 encryption protocol. This article will be updated as new information becomes available.
Disabling TLS 1.1 for other Salesforce services (e.g. Marketing Cloud, Heroku, Pardot, SalesforceIQ, etc.) is currently being evaluated. Additional information will be available once plans and deadlines are confirmed.
?TLS stands for Transport Layer Security. It is a protocol that ensures confidentiality and data integrity between two communicating applications. Today, this security protocol is the most common, and is therefore used for web browsers and other applications that require secure data exchange over the network. TLS ensures that the connection to the remote endpoint is correct through encryption and endpoint authentication. The currently available versions are TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3.
Salesforce web and API connections and email delivery. mail, use TLS as a primary security component. HTTPS (web) and STARTTLS SMTP (email) protocols use TLS as a primary security component.
Windows Vista, XP, or earlier operating systems are not compatible and cannot be configured to support TLS 1.1 or TLS 1.2.
Internet Explorer 7 or earlier (desktop) version
Internet Explorer 10 or earlier (mobile) version
Microsoft Edge
Mozilla Firefox
Firefox 27 or later
Compatible when using TLS 1.2 by default.
Compatible, but not default.
To use about:config to enable TLS 1.1 or TLS 1.2, update the security.tls.version.max configuration value to "2" for TLS 1.1 or "3" for TLS 1.2.
Firefox 23 or earlier
Not compatible when using TLS 1.2.
Google Chrome
Compatible with the latest version (regardless of operating system).
Google Chrome 38 or later
Compatible when using TLS 1.2.
Google Chrome 30-37
Compatible with Windows XP SP3, Vista or later (desktop), OS X 10.6 (Snow Leopard) or later (desktop), Android 2.3 (Gingerbread) or later (mobile).
Google Chrome 29 or earlier
Not compatible when using TLS 1.2.
Browser for Google Android operating system
Android 5.0 (Lollipop) or later
Compatible when using TLS 1.2.
Android 4.4 (KitKat)-4.4.4
May be compatible when using TLS 1.2 or later. Some devices running Android 4.4.x may not support TLS 1.2.
Android 4.3 (Jelly Bean) or earlier
Not compatible when using TLS 1.2.
Apple Safari
Safari 7 or later (desktop) for OS X 10.9 (Mavericks) or later
Compatible when using TLS 1.2 by default.
Safari 6 or earlier (desktop) for OS X 10.8 (Mountain Lion) or earlier
Not compatible when using TLS 1.1 or later encryption.
Safari 5 or later (mobile) for iOS 5 or later
Compatible when using TLS 1.2 by default.
Safari (mobile version) for iOS 4 or earlier
Not compatible when using TLS 1.2.
Using a Web Browser
Depending on the access point, a user who tries to access an organization through a web browser that uses TLS 1.1 after the Require TLS 1.2 or later for HTTPS connections setting is enabled receives an error message that advises them on what next steps to take to resolve it. this incompatibility.
See summary table below.
| Access point | User error message | Message language |
|
login.salesforce.com |
The error message is only displayed after the user has logged in through this page. |
Displayed in the user's Salesforce language. |
|
Login page for My Domain feature |
Displayed in the organization's standard language. |
|
|
Site or community |
An error message is displayed when you visit this page. |
Displayed in the Salesforce language of the site guest user. |
|
Web-to-Lead or Web-to-Case |
An error message appears when sending data from an external page to Salesforce. Submitted data is archived without creating a lead or referral. To repeat these archived submissions, contact Salesforce Support and log a case. | |
|
Login or password recovery page of the client or partner portal (not through the site) | An error message is displayed when you visit this page. |
Displayed in the standard portal language. |
See below for more information (depending on your browser and operating system).
Compatible with the latest version (regardless of operating system).
Java 8 (1.8) or later
Compatible when using TLS 1.2 by default.
Enable TLS 1.2 via the Java system property (https.protocols) for HttpsURLConnection. To enable TLS 1.2 for connections other than HttpsURLConnection, configure the enabled protocols in the generated SSLSocket and SSLEngine instances within the application source code. If you cannot implement a newer version of Oracle Java, we recommend using IBM Java temporarily.
Java 6 (1.6) or earlier
Not compatible when using TLS 1.2. If you cannot implement a newer version of Oracle Java, we recommend using IBM Java temporarily.
Java (IBM)
Compatible when using TLS 1.2 or later by default. Optionally set if the application or library being called uses SSLContext.getinstance("TLS").
Java 7 or later, Java 6.0.1 Service Refresh 1 (J9 VM2.6) or later, Java 6 Service Refresh 10 or later
Enable TLS 1.2 through the Java system property (https.protocols) for HttpsURLConnection and the Java system property (com.ibm.jsse2.overrideDefaultProtocol) for SSLSocket and SSLEngine connections (as recommended in IBM documentation). If necessary, set com.ibm.jsse2.overrideDefaultTLS=true .
NET 4.6 or later
Compatible when using TLS 1.2 by default.
NET 4.5, 4.5.1, and 4.5.2 do not support TLS 1.2 by default. Enabling can be done in two ways described below.
Method 1.
.NET applications can enable TLS 1.2 directly in the software code by configuring System.Net.ServicePointManager.SecurityProtocol to enable SecurityProtocolType.Tls12 and SecurityProtocolType.Tls11. Below is a sample C# code.
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
Method 2.To enable TLS 1.2 by default without changing the source code, set the DWORD (SchUseStrongCrypto) value in the following two registry keys (if not present, user created): "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" and " HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". Although version 4.0.30319 is present in these registry keys, .NET 4.5, 4.5.1, and 4.5.2 also use these values. However, these registry keys will enable TLS 1.2 by default on all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on the system you are using. That's why we recommend testing this change before deploying it to production servers. Additionally, this change is available as a registry import file. However, these registry values will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.
NET 4.0 does not support TLS 1.2 by default. To enable TLS 1.2 by default, install the .NET Framework 4.5 or later and set the DWORD (SchUseStrongCrypto) value in the following two registry keys (user-created if not present): "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\ v4.0.30319" and "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319". However, these registry keys may enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on the system you are using. We recommend that you test this change before deploying it to production servers. Additionally, this change is available as a registry import file.
However, these registry values will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.
NET 3.5 or earlier
Not compatible when using TLS 1.2.
Compatible with the latest version (if you have an operating system that supports TLS 1.2).
Python 2.7.9 or later
Compatible when using TLS 1.2 or later by default.
Python 2.7.8 or earlier
Not compatible when using TLS 1.2 or later encryption.
Compatible with the latest version (when linked with OpenSSL 1.0.1 or later).
TLS 1.2 is enabled by default if you have OpenSSL 1.0.1 or later. Using the symbol:TLSv1_2 (preferred) or:TLSv1_1 with the ssl_version parameter of the SSLContext object ensures that TLS 1.1 or earlier is disabled.
Ruby 1.9.3 or earlier
Although the :TLSv1_2 symbol is not present in Ruby 1.9.3 or earlier, Ruby supports its addition and compilation with OpenSSL 1.0.1 or later.
Microsoft WinInet
Compatible when using TLS 1.2 by default.
Windows Server 2008 R2-2012
Compatible by default (if you have Internet Explorer 11). If you have Internet Explorer 8, 9, or 10, TLS 1.2 is enabled by the user or administrator.
Not compatible when using TLS 1.2.
Microsoft Secure Channel
Compatible with the latest version.
Windows Server 2012 R2 or later
Windows 8.1 or later
Compatible when using TLS 1.2 by default.
Windows Server 2012
TLS 1.2 is disabled by default, but is available if the application supports it. The TLS 1.1 and TLS 1.2 protocols can be enabled by default within the registry registry import file.
Windows Server 2008 R2
Compatible by default in client mode (if Internet Explorer 11 is installed). If you don't have Internet Explorer 11, or if you need to connect your Salesforce system to a service running on that type of system, TLS 1.2 may be enabled by default within the registry. Additionally, these registry settings are available as a registry import file.
Windows Server 2008 or earlier
Windows Vista or earlier
Not compatible when using TLS 1.2.
Windows Server 2012 R2 or later
Windows 8.1 or later
Compatible when using TLS 1.2 by default.
Windows Server 2008 R2 SP1 and 2012
How can we help end users manage this change?
When accessing Salesforce using TLS 1.1, users (including internal and external community members) may be notified to update their web browser or browser settings.
To do this, use the methods below.
AppExchange package.
The TLS 1.1 Compatibility User Message package will be available on the AppExchange shortly. This package is designed to deliver in-app notifications to TLS 1.1 users that provide detailed instructions for TLS 1.2 compliance.
Visualforce page controller.
If you have experience with Visualforce and Apex development, check the value of ApexPages.currentPage().getHeaders().get("CipherSuite"), if not null, for the substring "TLSv1" (including leading and trailing spaces). When enabled, TLS 1.1 is used and the Visualforce page may display a notification to update your web browser or browser settings.
How can I identify users in my organization making TLS 1.1 connections?
This Knowledge article describes three ways to identify users affected by this change (including login history, reports, and Workbench):
NOTE.The login history report for all users in the organization can only be viewed and executed by users with the permission"User management" . If you do not have the Manage Users privilege, contact an administrator who has the necessary privileges to run the Login History report for all users.
How to test before disabling TLS 1.1?
A new Critical Updates Console option, "Require TLS 1.2 for HTTPS connections," will be available in the coming weeks.
What to do when using an intercepting HTTPS proxy server on the network?
Some networks intercept outgoing HTTPS traffic by using a proxy that generates its own certificates, so communications with Salesforce and other endpoints that are not encrypted can be closely monitored. These proxies create their own TLS connections to Salesforce. Networks using this type of proxy must ensure they support TLS 1.2 and must select TLS 1.2 when connecting to Salesforce. Deviations from standard behavior may occur if the proxy server does not support TLS 1.2 or chooses TLS 1.1 instead of TLS 1.2 when connecting to remote endpoints.
- Prevent the HTTPS intercepting proxy from intercepting HTTPS connections to the *.salesforce.com and *.force.com subdomains of Salesforce. This algorithm is preferred because it provides end-to-end privacy between end users' web browsers and Salesforce.
- If HTTPS interception is required by company policy or cannot be removed or otherwise excluded, use a new version of the proxy server that supports TLS 1.2 or, at a minimum, TLS 1.1.
- If the HTTPS intercepting proxy does not support TLS 1.2 but selects TLS 1.1 by using it in the original ClientHello messages, allow the proxy configuration to select TLS 1.2 instead of TLS 1.1 when connecting to the *.salesforce.com and *.force.com subdomains of the system Salesforce.
A new Critical Updates Console option, Require TLS 1.2 for HTTPS connections in communities and Salesforce sites, will be available in the coming weeks.
Before testing this update in a production organization, customers are encouraged to test it in a secure environment to confirm end-to-end compatibility.
To prepare for enabling TLS 1.2, we recommend that you proactively review the impact of disabling TLS 1.1 on your organization's users by using the new Critical Updates Console setting: Require TLS 1.2 or later for HTTPS connections.
Email-to-Case agent client support for TLS 1.2 and newer versions is only possible with a Java update.
Please update your Java environment to version 8 as indicated in the table below to ensure Email-to-Case functionality.
IMPLICATIONS FOR APPEXCHANGE APPLICATIONS
Determine compatibility of AppExchange applications with Salesforce's TLS 1.1 shutdown process by contacting the vendor and/or partner directly.
TLS is a successor to SSL, a protocol that provides a reliable and secure connection between nodes on the Internet. It is used in the development of various clients, including browsers and client-server applications. What is TLS in Internet Explorer?
A little about technology
All enterprises and organizations that engage in financial transactions use this protocol to prevent eavesdropping of packets and unauthorized access by intruders. This technology is designed to protect important connections from attacks by intruders.
Basically, their organizations use a built-in browser. In some cases - Mozilla Firefox.
Enabling or disabling a protocol
It is sometimes impossible to access some sites because support for SSL and TLS technologies is disabled. A notification appears in the browser. So, how can you enable protocols so you can continue to enjoy secure communications?
1.Open Control Panel via Start. Another way: open Explorer and click on the gear icon in the upper right corner.
2.Go to the “Browser Options” section and open the “Advanced” block.
3.Check the boxes next to “Use TLS 1.1 and TLS 1.2.”
4.Click OK to save your changes. If you want to disable the protocols, which is highly not recommended, especially if you use online banking, uncheck the same items.
What is the difference between 1.0 and 1.1 and 1.2? 1.1 is only a slightly improved version of TLS 1.0, which partially inherited its shortcomings. 1.2 is the most secure version of the protocol. On the other hand, not all sites can open with this protocol version enabled.
As you know, the Skype messenger is directly connected to Internet Explorer as a Windows component. If you do not have the TLS protocol ticked in the settings, then problems may arise with Skype. The program simply will not be able to connect to the server.
If TLS support is disabled in Internet Explorer settings, all network-related functions of the program will not work. Moreover, the safety of your data depends on this technology. Do not neglect it if you perform financial transactions in this browser (purchases in online stores, transferring money through online banking or e-wallet, etc.).
