Hello anybody describe me. I am always confused .
what is difference between HTTPS, SSL and PCI compliance.
how HTTPS work ??
how SSL work ??
how PCI work ??
SSL
Definition: SSL (Secure Sockets Layer) is a security protocol commonly used in circumstances like E-Comm, with Verisign etc to protect personally identifiable information during web transactions, as well as other sensitive data like credit card numbers and logins. SSL certificates generally need to be bought and installed on your web server.
More reading here: https://www.globalsign.com/en/ssl-information-center/what-is-an-ssl-certificate/
HTTPS
Definition: HTTPS is HTTP + SSL certificate.
HTTPS (Hyper Text Transfer Protocol Secure) is the secure version of HTTP. The "S" implies that all data that is sent over the browser is encrypted.
Example: Google Searches
PCI
Definition: PCI DSS Compliance Payment Card Industry Data Security Standard is the global data security standard for credit card payments. I agree that it doesn't make sense to "implement PCL like SSL". PCI compliance governs everything from the hardware (card reader or point of sale) to your payment gateway. It's much easier to go with a payment processor that is already PCI compliant, as adhering to standards independently is probably not worth your time. Square has a basic guide here: https://squareup.com/guides/pci-compliance
SSL, which has since been replaced by Transport Layer Security (TLS), is basically a set of cryptography protocols to ensure private communication from a client endpoint (e.g. web browser) to a server. Apart from private communication, when properly implemented, it also includes mutual authentication of the client and server (i.e. the client verifies that it's communicating with the server it thinks it's communicating with and the server verifies that the client is really who they claim they are) and some kind of tamper resistance; these are to prevent man-in-the-middle attacks and provide a partial defense against replay attacks.
HTTPS just means that you're using HTTP over TLS or SSL.
As I describe in my comments, PCI standards are very different than either SSL or HTTPS. PCI standards are exactly that - a standard for data security, not a specific network or cryptography protocol.
Here is a description of what PCI compliance means (from the PCI Compliance Guide FAQ):
The Payment Card Industry Data Security Standard (PCI DSS) is a set of
security standards designed to ensure that ALL companies that accept,
process, store or transmit credit card information maintain a secure
environment.
It's very important to note that there's a lot more to PCI compliance (and to software security in general) than just secure data exchange. In fact, the FAQ I link to above addresses that specifically; in response to the question "Am I PCI compliant if I have an SSL certificate?" they say the following:
No. SSL certificates do not secure a web server from malicious attacks
or intrusions. High assurance SSL certificates provide the first tier
of customer security and reassurance... but there are other steps to
achieve PCI compliance.
Some examples of other things you have to consider for data security:
Do you store passwords and other sensitive data properly on your server (e.g. salting them, etc.)?
Do you have adequate network security (e.g. firewalls) in place? (Note that, as described in the book I link to below, even then you shouldn't assume that merely having a firewall is a complete defense against security problems).
Do you have adequate physical security in place? For example, how feasible would it be for someone to walk into your server room and gain access to the servers? Do you have to scan a badge to get in to the server room, and is access restricted to authorized employees?
Do you run code with least permissions?
Has code been reviewed and tested for common security bugs like buffer overruns and integer overflows?
There's an excellent book out there called 24 Deadly Sins of Software Security that describes common security bugs.
Related
Suppose I have a mobile app which makes API calls to a server using HTTPS.
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
If you control the client, then of course yes. Anything the client knows, its user may also know.
Without controlling the client, no, an external attacker cannot inspect or change https traffic unless they know the session keys. For that, they would typically use a fake certificate and make the client accept it (it won't do it by itself, and we are back at controlling the client).
Would a malicious user be able to install Wireshark + Android emulator to inspect the API calls and by doing so get access to sensitive data like an API key?
I guess my question is whether Wireshark (or some other tool) can inspect the request before it gets encrypted.
Yes this possible if the user controls the device he wants to intercept the API calls.
In the blog post Steal that API Key with a Man in the Middle Attack I show how a proxy tool(MitmProxy) can be used to intercept and introspect the https calls:
While we can use advanced techniques, like JNI/NDK, to hide the API key in the mobile app code, it will not impede someone from performing a MitM attack in order to steal the API key. In fact a MitM attack is easy to the point that it can even be achieved by non developers.
In order to protect https calls from being intercepted, introspected and modified the solution is to use certificate pinning:
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
and you can learn how to implement it in the article Securing HTTPS with Certificate Pinning on Android:
In this article you have learned that certificate pinning is the act of associating a domain name with their expected X.509 certificate, and that this is necessary to protect trust based assumptions in the certificate chain. Mistakenly issued or compromised certificates are a threat, and it is also necessary to protect the mobile app against their use in hostile environments like public wifis, or against DNS Hijacking attacks.
You also learned that certificate pinning should be used anytime you deal with Personal Identifiable Information or any other sensitive data, otherwise the communication channel between the mobile app and the API server can be inspected, modified or redirected by an attacker.
Finally you learned how to prevent MitM attacks with the implementation of certificate pinning in an Android app that makes use of a network security config file for modern Android devices, and later by using TrustKit package which supports certificate pinning for both modern and old devices.
While certificate pinning raises the bar, its still possible to intercept, introspect and modify https traffic, because it can be bypassed, as I demonstrate in the article Bypassing Certificate Pinning:
In this article you will learn how to repackage a mobile app in order to make it trust custom ssl certificates. This will allow us to bypass certificate pinning.
Conclusion
While certificate pinning can be bypassed I still strongly recommend its use, because it will protect the https communication channel betwwen your mobile app and API server in all other scenarios where is not the user trying to perform the Man in the Middle attack:
In cryptography and computer security, a man-in-the-middle attack (MITM) is an attack where the attacker secretly relays and possibly alters the communications between two parties who believe they are directly communicating with each other. One example of a MITM attack is active eavesdropping, in which the attacker makes independent connections with the victims and relays messages between them to make them believe they are talking directly to each other over a private connection, when in fact the entire conversation is controlled by the attacker. The attacker must be able to intercept all relevant messages passing between the two victims and inject new ones. This is straightforward in many circumstances; for example, an attacker within reception range of an unencrypted wireless access point (Wi-Fi[1][2]) could insert themselves as a man-in-the-middle.[3]
Going the extra mile?
OWASP Mobile Security Project - Top 10 risks
The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.
HTTPS request is encrypted on your host (client) before sending over the network, so it is not available for Wireshark. Wireshark can get hostname of the HTTPS web serserver you connect but not the URL.
i'm developing an android app that must be PCI PA-DSS compliant, my question is about this requirement in the PA-DSS_v3-1 document
3.3.1 Use strong cryptography to render all payment application passwords unreadable during transmission.
let's say i have a "change your pasword" feature in my app that transmits the user's account password over a ssl/tls encrypted connection to the server. Is this encryption sufficient to comply to the requirement? do i need to implement some kind of encryption before sending it through ssl?
thank you.
The PCI standard can be vague at times and a little 'open ended', but from our experience, its quite OK as you have it.
SSL/TLS IS the encryption, just use it for your forgotten password feature and you'll be fine.
I'm trying to understand more why I shouldn't use WCF transport security over the internet. From the answer here I'm told the chain of hops may not be secure. But isn't transport security just like https (which is widely used on the internet)? Or maybe I should ask, what is the difference between wcf transport and https?
If I need to explain myself clearer, please comment.
Thanks
Transport security is indeed very similar to HTTPS (and identical in many cases). What it provides you is an encrypted tunnel between your client and the server. Providing there's a direct connection from your client to your server, it's perfectly fine (providing that your client verifies that it got the right server certificate). If your client is talking to another intermediate server, on which you rely to pass the message to your server - then that intermediate server would get unencrypted data.
An example :
You have a company that processes payments. Because of some regulations, you need servers in each country, and those in turn pass the requests to your main server in the US.
You want to make sure that even if the local hosting company tries to find out what details are being passed, they can't.
That is what Message Security provides you - you trust only the client and your main servers, so you want only them to be able to encrypt and decrypt.
With Transport Security, there would be two transitions - the client will encrypt, and the intermediate server will decrypt. Then it will encrypt again, and your main servers will decrypt. As you can see, there is an intermediate phase where the data is plain in RAM in the intermediate server.
This MSDN article describes it very well, and where to use each :
MSDN
Look at another answer on the link you gave. It explains that the case where transport security not sufficient is when the client doesn't check server certificate. I quoted the answer below:
Yes it is 100% secure when the clients (which most clients do) validate the server certificate.
The multiple hop scenario mentioned here is complete bogus. This is only true when the same message travels through various applications. Like for example several application brokers. If these brokers do not communicate securely then the message can be read by intermediate network sniffers.
In other words, client/server communication over the internet is 100% secure even when there are a million routers in between but it is only secure when the client validates the server certificate as the client could connect to a man-in-the-middle host that could impersonate the server with a false certificate. If the client does not validate the certificate the message could be compromised.
I'm trying to understand more why I shouldn't use WCF transport security over the internet
You should not because (Quoting from here).
Transport Security
Transport security is used to provide point-to-point security between the two endpoints (service and client). If there are intermediary systems between client and the service, each intermediate point must forward the message over a new SSL connection.
Message Security
When using message security, the user credentials and claims are encapsulated in every message using the WS-Security specification to secure messages. This option gives the most flexibility from an authentication perspective. You can use any type of security credentials you want, largely independent of transport, as long as both the client and service agree.
So, a few questions:
1) Does using a client certificate during TLS provide non-repudation?
1a) Follow-up: If so, does having a load balancer handle the transaction still provide this assurance at the end server/service level?
2/2a) Same questions as above, but for message integrity.
I know the answers for MLS, but I'm not sure about TLS. If I understand correctly, TLS involves a handshake where the shared secret is established, and that is used to secure the pipe - so none of these things hold, since each message uses only the shared secret.
Does using a client certificate during TLS provide non-repudation?
No. This is unfortunate, as it engages in everything that is necessary to implement it except making the digital signature available. It might be possible to stand up in court as an expert witness and make a case that as it all happens under the hood the transaction should be non-repudiable anyway, but I would much rather prefer to be able to produce an actual digital signature in court. Then there is nothing to debate.
2/2a) Same questions as above, but for message integrity.
TLS provides message privacy, message integrity, and authentication of at least one of the peers (unless you have broken that). It doesn't provide authorization, and it doesn't provide non-repudiation as above.
Does using a client certificate during TLS provide non-repudation?
1a) Follow-up: If so, does having a load balancer handle the
transaction still provide this assurance at the end server/service
level?
TLS is about transport level security (hence the name Transport Layer Security). It aims to secure the communication between the client and the server (possible a load-balancer), according to the specification:
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications.
You could in principle keep the entire TLS exchange, in particular keeping the handshake to prove that the client-certificate signed the content of the Certificate Verify message. You would also have to keep the various generated/calculated intermediate values (in particular the master secret, and subsequently the shared key). There is one problem with this: the TLS specification requires (only with "should") the pre-master secret to be deleted. This could make proving the path back from data to client certificate rather difficult. (You would certainly have to tweak SSL/TLS stacks to record all this too.)
In addition, recording all this would be under the application protocol (assuming HTTPS here, but the same would apply to other protocols). This would certainly be another layer before you get to the actual data you want not to be repudiated. (The problem is that you may have to record the entire session for proof, without being able to select with request/response to isolate.)
You may also run into further problems when it comes to session resumption (for example) and generally parallel requests. This would certainly add to the confusion.
Overall, it's not what TLS is designed for. Non-repudiation is about being able to keep a proof of the exchange, possibly to be able to display it in court or similar. Explaining to people (who might not have the technical background) how you make the link between the interesting data and the client certificate could be challenging.
2/2a) Same questions as above, but for message integrity.
TLS guarantees the integrity of the communication (see introduction to the specification). (All of this, of course, provided that the client verifies the server certificate correctly, although you should be able to detect a MITM if you're using client certificates anyway.)
Integrity will only be guaranteed up to the point where the TLS connection ends. This will be the load-balancer itself if you're using one. (Of course, it's better to link the load-balancer to its worker nodes via a network that can be trusted.)
If you're after a system where clients can send non-repudiating messages, which can be audited at a later date, you should look into message level solutions.
I'm developing a product that needs to act as a server over a local network for other client applications to connect to, under the following constraints:
The data exchanged is very valuable, and we have no guarantee over the security of the users' network or the machine acting as a server. Therefore any SSL certificate could potentially fall into "the wrong hands".
To minimise disruption to the user experience, any non-electronic means of identifying the server to the client should be limited to information that can be written on a post-it (i.e. IP address, passcode rather than exchanging key files).
Given these, our current SSL strategy is:
Do not install any SSL certificates into any trusted stores or sign any certificates against a CA certificate - this could give a potential attacker a front-door key to all the client machines
SSL certificates will therefore be self-signed. This offers no man in the middle protection, because we have no way of verifying the server. It does however offer eavesdropping protection to those users who have insecure networks but secure servers.
Implement a "passcode" system over the top using Rijndael symmetric encryption, so even if the certificate is compromised there is some eaves-dropping protection (I know, many leaky buckets - but better than nothing). This passcode can be regularly regenerated with minimal interruption to the user experience of the clients.
Within these constraints, is there a more secure strategy for the client and server to communicate?
In the end we developed a system where we could generate a new SSL certificate in memory for each channel we were going to support. This cannot provide protection against Man in the Middle but does at least protect against eavesdropping (unless the third party has access to the memory of the server at time of transmission, in which case all security is moot anyway!).