On 2nd edition of "Programming WCF Services" By Lowy, ch 10, page 512.
Lowy said about Transport security: Its main downside is that it can only guarantee transfer security point-point, meaning when the client connects directly to the service. Having multiple intermediaries between the client and the service renders Transport security questionable, as those intermediaries may not be secure. Consequently, Transport security is typically used only by intranet applications.
HTTPS is one of Transport security options, How previous paragraph applies to HTTPS ?!!, HTTPS encrypts every thing all the way from start to end points. Also every e-commerce application in the world is using HTTPS, how you can limit it to intranet applications!!
Thanks
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party).
Related
I want to strictly enforce TLS on all inbound/outbound emails from gmail (gsuite basic) for a particular organization/domain. I did read this article:
https://support.google.com/a/answer/2520500?hl=en
It asks to create an address list to setup inbound/outbound rule to enforce TLS. However I want to have TLS enforced irrespective of address and want to enable following behavior:
Outgoing mail: Mail won't be delivered and will bounce. You'll get a non-delivery report (NDR). Only one send attempt is made (no tries again).
Incoming mail: Mail is rejected without any notification to you, although the sender will receive an NDR.
Any suggestions on how this can be accomplished?
You can’t do that, in fact based in this article at point 6.:
https://support.google.com/a/answer/2520500?hl=en
“You must create a domain or address list to enforce TLS compliance for any inbound or outbound messages”
Gmail by default will use TLS, however, if the destination domain can’t establish TLS connection, Gmail will do an insecure connection. However, nowadays all domains are all by default establishing TLS connection and transmitting data over it. It’s rare you will find a domain that doesn’t support TLS connection.
Therefore, first of all, you should know which domains you usually contact that doesn't support TLS connection, and listed in the TLS compliance rules.
The idea of this policy is not making a long list of domains but only a few that customers already know that they don’t support TLS connection hence list them on the TLS.
There is a feature for a higher message encryption but is available for G Suite Enterprise edition: https://support.google.com/a/answer/6374496?hl=en
In fact what it may be a workaround is to Send and receive your email first to an external server that allows you to achieve this.
If this is the case you should Set up:
Set up an inbound mail gateway: https://support.google.com/a/answer/60730?hl=en
Set up an outbound mail gateway: https://support.google.com/a/answer/178333?hl=en
An consider a third party tool as : https://zix.com/products/email-encryption
I have read a lot of articles saying that in WCF you have two types of security one is transport level and other is message level. Transport level security must be used when you have intranet connection as it provides point to point security and underlying protocol should be SSL....
But if I search on how to secure public websites they all say use HTTPS(SSL) again SSL.
These two statements are contradictory.
Questions:
What exactly is the meaning of point to point security here?
If SSL is only point to point(and not end to end) then why people use it for public websites?
HTTPS encrypts data from point-to-point, and once the data reaches one of the points and is decrypted, no security guarantee is made from that point onwards. Intermediary nodes, however, cannot read the information.
Message security, on the other hand, can encrypt data to be decrypted only by a certain recipient, which can be a separate entity from the receiving end. The receiving end might eventually forward the encrypted message to the intended recipient who will be able to decrypt the message.
An analogy would be email. If you establish a connection with your mail server using transport security (e.g. HTTPS), any information is guaranteed to be secured from your machine to the mail server. However, anyone with access to the mail server (e.g. server administrators) will be able to read the content of the email.
On the other hand, if you use message security to encrypt the message so only a specified recipient can decrypt it, the actual email message is encrypted (and not simply the communication between you and the server), so that even once the message is received by the server, it is still encrypted. Only when the email server forwards your message to your intended recipient, the recipient can decrypt the message using his own private key, thereby keeping the email private across a whole path of delivery while not requiring direct communication by the sender and that recipient, as is required by transport-level security.
Of course, some parts of the message must remain visible to the email server, for example the recipients address, and so you may want to use both levels of security: message security will ensure the mail server (or any party except the recipient) can't read the content of your email, and transport security will additionally ensure that a third party listening in to the communications between you and your mail server can't find out who you're sending an email to (unless the mail server divulges that information to that third party
Taken from WCF Transport security weakness
Read more here https://msdn.microsoft.com/en-us/library/hh273109(v=vs.100).aspx
Answer to question 2 :
Because once it reached to the IIS Server which is hosted by the company itself/or in Data center which has all firewalls and other security measures which is hard to bypass which means no one can read your message from that server unless is can hack everywhere it saves oecerhead of tcp security.
Don't know much about encryption...
Say I'm preparing a SAML request to submit to an identity provider. Why would I need to apply an x.509 certificate to this request? Is transmission over SSL alone not secure enough?
In the case of SAML, message-level security (i.e. the XML itself is signed and sometimes encrypted) because the communication involves parties that don't communicate directly. SSL/TLS is for transport-level security, only used between the two parties that are communicating directly and for the duration of this communication only.
Depending on which SAML binding you use, the dialog can look like this (e.g. along the lines of Shibboleth):
User's browser connects to Service Provider (SP)
SP gives the user a SAML request, not necessarily visible, but hidden within a form or equivalent.
User's browser (in a direct connection to the IdP) sends the SAML request to the IdP.
The user authenticates with it and gets a SAML response back.
The user's browser sends that SAML response to the SP.
In this scenario, there is no direct SSL/TLS connection between the SP and the IdP, although all 3 parties are involved. (Some variants of this involve a back-end communication between SP and IdP for attributes, but that's a different problem.)
An SSL/TLS connection wouldn't be sufficient for the IdP to know that the SAML request came from an SP for which it's allowed to authenticate and release attribute, since the connection to the IdP comes from the user's browser, not the SP itself. For this reason, the SP must sign the SAML request message before handing it to the user's browser.
An SSL/TLS connection wouldn't be sufficient for the SP to know the SAML response came from an IdP it trusts. Again, that's why the SAML response itself is also signed.
What applies to signing also applies to encryption, if the middle party, i.e. the user, isn't meant to see what's in the SAML message and/or if the connection between the user and the SP or IdP isn't over SSL/TLS (usually, it should be over HTTPS).
Yes - SSL is enough - but SSL is only point-to-point. You cannot secure your connection using SSL if there are a few intermediaries in the way between your source and your target machine.
In that case, e.g. when transmitting over the internet, you must safeguard the actual message, instead of the transport-level. That's why you need to encrypt the XML (or at least parts of it).
Marc
All that HTTPS will do is encrypt the communication between two points and prevent eavesdroppers -- it won't confirm who it was that sent the message. Neither will it assure secure communication if your message is then forwarded.
If you sign your request with the X.509 certificate you can be assured the decryptor has the shared secret contained in certificate. In other words, you can be assured the message can only be decrypted by the organisation you want it to be decrypted by.
In your case, the X.509 encryption requirement means that you should be assured that the identity provider is the only organisation that will receive your request.
A useful Wikipedia primer is here.
Most likely because they want to authenticate you (the client). HTTPS can be used for client authentication, but it rarely is in practice.
In practice, you could use HTTPS (SSL/TLS) to protect your SAML message. But you would want to use two-way SSL certificate verification/validation, meaning your client would need to verify the server's X.509 certificate and the server would need to be configured to perform client authentication, which would require it to check an X.509 certificate that the client presents. So, the client would need its own certificate anyway.
SSL/TLS is not really designed for this...it was/is designed to protect web traffic from being seen while in transport and for the client to be able to tell what server they are talking to and sending sensitive information to (it was really designed for e-commerce where the client (user buying something) knows who they are sending their credit card information to). In the case of SAML, the whole point is for the parties to know that the information they are exchanging has not been altered in transport and that each is talking to who they think they are. Using certificates to sign/encrypt that message itself accomplishes that.
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.
I'm looking into WCF & Security.
There are several security modes but the big picture is that there are 2 main "layers" you can secure : Transport or Message.
Can someone explain this in more depth please?
What do I have to imagine when I'm securing Transport, how does it work, etc.
it is pretty much as you'd expect, transport security secures the transport - e.g. SSL over HTTP, whereas message security secures messages. Here's an msdn overview for reasons to use message security:
http://msdn.microsoft.com/en-us/library/ms733137.aspx
and an overview for transport:
http://msdn.microsoft.com/en-us/library/ms729700.aspx
(From the message security link):
Windows Communication Foundation (WCF) has two major modes for providing security (Transport and Message) and a third mode (TransportWithMessageCredential) that combines the two. This topic discusses message security and the reasons to use it.
What Is Message Security?
Message security uses the WS-Security specification to secure messages. The WS-Securityspecification describes enhancements to SOAP messaging to ensure confidentiality, integrity, and authentication at the SOAP message level (instead of the transport level).
In brief, message security differs from transport security by encapsulating the security credentials and claims with every message along with any message protection (signing or encryption). Applying the security directly to the message by modifying its content allows the secured message to be self-containing with respect to the security aspects. This enables some scenarios that are not possible when transport security is used.
Reasons to Use Message Security
In message-level security, all of the security information is encapsulated in the message. Securing the message with message-level security instead of transport-level security has the following advantages:
• End-to-end security. Transport security, such as Secure Sockets Layer (SSL) only secures messages when the communication is point-to-point. If the message is routed to one or more SOAP intermediaries (for example a router) before reaching the ultimate receiver, the message itself is not protected once an intermediary reads it from the wire. Additionally, the client authentication information is available only to the first intermediary and must be re-transmitted to the ultimate receiver in out-of-band fashion, if necessary. This applies even if the entire route uses SSL security between individual hops. Because message security works directly with the message and secures the XML in it, the security stays with the message regardless of how many intermediaries are involved before it reaches the ultimate receiver. This enables a true end-to-end security scenario.
• Increased flexibility. Parts of the message, instead of the entire message, can be signed or encrypted. This means that intermediaries can view the parts of the message that are intended for them. If the sender needs to make part of the information in the message visible to the intermediaries but wants to ensure that it is not tampered with, it can just sign it but leave it unencrypted. Since the signature is part of the message, the ultimate receiver can verify that the information in the message was received intact. One scenario might have a SOAP intermediary service that routes message according the Action header value. By default, WCF does not encrypt the Action value but signs it if message security is used. Therefore, this information is available to all intermediaries, but no one can change it.
• Support for multiple transports. You can send secured messages over many different transports, such as named pipes and TCP, without having to rely on the protocol for security. With transport-level security, all the security information is scoped to a single particular transport connection and is not available from the message content itself. Message security makes the message secure regardless of what transport you use to transmit the message, and the security context is directly embedded inside the message.
• Support for a wide set of credentials and claims. The message security is based on the WS-Security specification, which provides an extensible framework capable of transmitting any type of claim inside the SOAP message. Unlike transport security, the set of authentication mechanisms, or claims, that you can use is not limited by the transport capabilities. WCF message security includes multiple types of authentication and claim transmission and can be extended to support additional types as necessary. For those reasons, for example, a federated credentials scenario is not possible without message security. For more information about federation scenarios WCF supports, see Federation and Issued Tokens.
Transport security, such as Secure Sockets Layer (SSL) only secures
messages when the communication is point-to-point. If the message is
routed to one or more SOAP intermediaries (for example a router)
before reaching the ultimate receiver, the message itself is not
protected once an intermediary reads it from the wire.
Misleading. A network router or switch (OSI Layer 2 and 3) will not have access to the message content if encrypted with Transport layer security (Server side SSL certificate) since the service side SSL certificate is needed to decrypt the message. Transport layer security secures the message between the client and intended destination IP address since only the destination service provider is assumed to have the SSL private certificate which is required to decrypt the message. A SOAP intermediary would only be able to read the content if the SOAP intermediary (i.e. ESB) was in fact the intended message destination that actually establishes the encrypted transport channel with the client, ensuring a secure channel from client to server regardless of the number of network hops, routers and switches, etc (OSI layers 2 and 3).
Message Level security would add security to the message and could encrypt parts of a message if a middleware ESB (intended SOAP Intermediary) needed to read parts of a message to make routing decisions (Content Based Routing) but shouldn't be able to read other parts of a message that should only be accessed by downstream systems.
With transport use are securing the channel you are using, and with message the message (content) you are sending.