I am working with Axis2 1.6.1 + Rampart 1.6.1 on the server side of a web service.
I've been asked to employ RSA 1.5 for message body encryption. From what I can tell (by inspecting captured SOAP messages), the default algorithm to encrypt the message body is Triple DES CBC. So I want to change that to RSA 1.5.
I am assuming that there is some property I need to set in my server policy XML file. However, I cannot figure out what property that might be. I have looked at example policy files, this page about WSS configuration, and this page about Rampart configuration, and various blogs and what-not.
If someone can point out an example policy or relevant configuration docs or whatever, I'll be very grateful. Thanks in advance for your help.
Refer to the WS-Security Policy Specification section 6.1. Why do you want to use RSA ? The given algorithm suites in the spec don't use RSA for encryption.
Related
Is there anyone with experience in using Azure API Management, and in particular with validating JWT tokens sent to it using the policy model?
I've configured the <validate-jwt> tag properly, but my tokens are signed asymmetrically so I need to use the <openid-config> tag to let the system know where to get the public key.
And in doing so, the system will call to that url over SSL/TLS, but in my case the host is configure to offer SSL/TLS with a self-signed certificate.
Is there any way to disable this? I know the official docs mention disabling certificate validation when it comes to calling the backend APIs, but this is a front-facing API. And setting that doesn't seem to work.
I also tried abusing the declarative model of the policies, to somehow run C# code that disables that, but to no avail.
Does anyone know any other way of doing this? Either disabling the validation, or forcing trust with the self-signed certificate.
Thank you, and have a good one.
EDIT: This is how my configuration looks like:
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized" require-expiration-time="true" require-scheme="https" require-signed-tokens="true">
<openid-config url="https://identityserverhost/.well-known/openid-configuration" />
<audiences>
<audience>audience</audience>
</audiences>
<issuers>
<issuer>issuer</issuer>
</issuers>
</validate-jwt>
The https://identityserverhost is served over https, but with a self-signed certificate, if this makes it more clear.
I don't think it's possible at the moment, would be a good feature though. You could switch to http instead of https in openid-config, if you're comfortable with that.
if you have the certificate you can load it on API Management
and validate the tokens by means of the following policy
<issuer-signing-keys>
<key certificate-id="my-rsa-cert" />
</issuer-signing-keys>
I have seen one or two questions about this but no definite answers. I have a customer requirement to implement a WCF-based client/server solution using Message Encryption AND HTTPS. I understand that WCF doesn't support this as standard, and the options are HTTP with Message Encryption, HTTPS without Message Encryption, or HTTPS with Message Credentials.
None of these will satisfy the customer requirement. I have control over both the service and the desktop-based clients. The service is hosted at my location and the clients access it over the internet.
I have dug around for days (and nights :( ) trying out custom bindings and so on, but whenever I try to combine message encryption with Https, I come up against this error:
"The binding contains both a SymmetricSecurityBindingElement and a secure transport binding element. Policy export for such a binding is not supported."
I would prefer to user username/password for authentication but I am prepared to use client certificates if this makes it possible. So far I haven't found any combination which is acceptable to WCF.
Is there any way to achieve this or am I just wasting my time? I would value a quick answer because my customer's deadline is drawing very near!
Thanks!
According to this, the special both mode for security (meaning both message and transport) is only supported in the NetMsmqBinding binding, which I'm guessing, is not an option for you. Does your client happen to be the NSA? (Just wondering why anyone would need their communication encrypted twice).
OK I've found a solution ...
Using IMessageInspector I intercepted the incoming and outgoing messages so that they can be encrypted and decrypted. Encryption uses a symmetric technique - best because asymmetric only allows encryption of short strings and is very slow.
The downside is that both ends need to have the private key of the certificate - so the cert needs to be installed on both client and server machines (or the key could be placed in config). This works for me though because the number of users is limited and all are under the control of the IT dept.
If I had more time I would have looked at setting up a second SSL connection with a different cert, purely to handle the certificate negotiation and avoid placing the cert on the client machine. Using SslStream was a possibility but I wasn't sure whether I could access key information to use for my own encryption, or whether this is held privately within SslStream class.
For now I'm just pleased to have it working before my deadline (only just though :) ) ...
I'm in the process of designing a REST Api and we're trying to decided how to do encryption. We are currently using https for all request/responses however various logs (dns, browser, ...) will log the plain text url. This raises an issue when we're sending sensitive data in the url, such as "www.mysite.com/user/credit-card-number/". Is there a way to leverage the SSL/TLS public/private keys to encrypt path parameters? For example, "www.mysite.com/user/credit-card-number/" turns into "www.mysite.com/encryptedstring".
I would highly recommend that you not put sensitive data in the URL. If you need something identifying, you could at least use a randomly generated String/UUID/token/whatever that maps to whatever it is that is being identified.
Handling manual encryption/decryption would depend on what language/framework you are using. For example, if you were using Java, then do some google searches on JSSE, which is Java's framework for SSL/TLS.
If you're looking for something to automajically do the encryption/decryption for you, I would think that would also depend on the framework you are using.
If I understand correctly, you are asking if urls are encrypted over an SSL/TLS channel. The answer is yes as this SO question points out. Over TLS, everything is encrypted between the client and server except the IP address and port of the targeted server. (This includes the http headers as well.)
EDIT:
After reading again, I see that you are interested in stopping the the URL being logged. I'm pretty sure the only way to do this is to change the url on the server. Not much help, but my suggestion is don't put the cc number in the url or use some kind of derived key instead.
I am currently in the process of integrating a WCF client into a java web service. The server requires the client to authenticate via certificate using SSL and the message to be signed.
I have successfully sent the message to the server through SSL, Signed, etc. However, the server response message is also signed but with a different certificate than the one used to authenticate the server.
The WCF client doesn't like this behavior. It failed with the message: "The incoming message was signed with a token which was different from what used to encrypt the body. This was not expected." The problem is described here in detail.
Looking around on Google I found it is possible to decouple the clients transport certificate from the singing certificate by implementing ClientCredentials and other security related classes, and adding a new extension. You can read all the details about it here. However I'm having some trouble figuring out where exactly do i have to extend to provide this same behavior for the server's certificate on client mode.
Any help on the subject or reference would be appreciated.
Thanks in advance.
Have a look here
This shows you how to create an custom ServiceCredentialsSecurityTokenManager that allows you to specify the various message signing and encryption certificates for requests and responses to and from the server.
I emphasise message because the problem as you describe it appears to me to be message security validation. The transport security is seaperate from the mechanism used to validate the message security, i.e. the message signature and message decryption.
Ignore the transport security as this is lower down in the WCF pipeline and appears to be working working correctly from your description. A seaperate concern is the message security. It appears that you need to be able to use a certificate for decrypting the response and a certificate for verifying the signature. The above article shows a example for enabling this type of certificate managment, it does detail how you could create behaviours and extensions to apply this to your client that is a seaperate concern. This depends on how you want to configure your proxies i.e. through code or through configuration.
The example article you linked too is not a complete implementation for what you require, it only provides for a certifiate for signing and a certificate for the transport client credentials.
You could create a hybrid ServiceCredentialsSecurityTokenManager that provides the transport certificate and the signing and decryption, this should be clear enough from looking at the SecurityTokenRequirement documentation
As far as I understand, https is http plus SSL/TLS.
What do I need to do if I want to add 3 more parameters for the header?
I found a file inside Mozilla's NSS - ssl3ext.c, but I don't understand it and don't know how to start. Need a clue from you guys..
Is this something about SSL/TLS extension? But it is far more complex right?
SSL/TLS is a transport layer. It's negotiated first, and then HTTP talks "over" it. To add more HTTP header parameters you do exactly the same as you would normally.
(to be completely clear - HTTPS is HTTP "on top" of TLS/SSL. The TLS/SSL connection is made first and then HTTP uses it just like it would use an unencrypted transport).
if a developer would like to add some
more information/parameters for his
SSL communication/handshaking, where
does the parameter should be located?
RFC 3546 'Transport Layer Security (TLS) Extensions' is the only defined way to add additional parameters to the SSL/TLS handshake.
You can add your extension to the Client Hello message. If the server recognizes it, it can respond with a corresponding extension on the Server Hello message. The server cannot send it unless it was requested, however.
is it inside the code for http header
or is it creating a new extension for
TLS like the server name
indication(SNI)?
It has nothing to do with HTTP. The SSL/TLS handshake is over before HTTP even begins.
I have looked into the code and RFC
for SNI but seems does not get any
clues?
Look at RFC 3546 for the extension format. The IANA manages the extension numbers.
http://www.iana.org/assignments/tls-extensiontype-values/
Note that there is no 'experimental' range for you to use. IMHO what you do over your own ports is your own business, but be aware of the possibility of conflict in the future.
Does adding more parameters to the
handshaking process will disturb the
current implementation?
Some SSLv3 and older TLS 1.0 servers will hang up on you if you send an extension they don't like. Major web browsers implement fallback reconnect logic without extensions.
will it broke the standard?
If your extension follows the general format for extensions defined in RFC 3546, the only (modern) standard you are breaking is that you are not using an IANA-blessed extension ID number. If your extension is generally useful, you should strongly consider submitting it for formal standardization.
You can add as many HTTP header parameters as you like, without concern for SSL. If you want to modify the SSL handshake, you should have the source to your SSL libraries on both sides of the connection.
I'm not sure what your trying to do here though. You could modify the ClientHandshake to include more/customer cipher suites. You could also define a custom content type. Currently the first byte in a TLS record determines the content type, which are as follows:
0x14 20 ChangeCipherSpec
0x15 21 Alert
0x16 22 Handshake
0x17 23 Application
Depending on what you are trying to do, you may be well served by adding a custom alert to the Alert Protocol. Alerts can be sent at any time, in either direction.
Customizing the protocol will break the standard, though you can do things like add cipher suites without changing the protocol. Between client certs and server certs, the protocol generally has everything most people need for authentication and encryption.