WSO2AM(1.10.0) is used in my organization as API gateway. Before releasing it to production, there are a few weakened protocols/ciphers found by a security company and they suggest disable these protocols as below,
TLSv1.0
3DES based ciphers
1024 bit Diffie-Hellman groups
Could anyone please suggest me how to turn them off and any side-effects?
Thanks,
Sean
You can disable TLSv1.0 by removing it from repository/conf/tomcat/catalina-server.xml file.
<Connector protocol="org.apache.coyote.http11.Http11NioProtocol"
port="9443"
bindOnInit="false"
sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
Ciphers can be disabled editing same file ciphers section.
ciphers="SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
More details can be found here. However, there are some known issues if you are running on jdk1.7. Refer here.
Related
The website is on Windows server 2019 with the AWS Load Balancer with ELB SecurityPolicy-2016-08. This policy definitely has the ECDHE_ECDSA cipher enabled. I have checked their docs. SSL certificate is installed on LB.
Running TLS Cipher Suites in PowerShell Windows server 2019 also shows these suits enabled but when running the website domain with SSLLabs or Zenmap. These suites are not appearing
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
or even these:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
any ideas? the website is ASP.NetFramework 4.7. but I hardly think it has anything to do with the ciphers. Any help will be appreciated. Thanks
Zenmap Snapshot
AWS load balancer Snapshot
PowerShell Snapshot
Meta: this isn't about programming, and I'm not sure 'how to operate cloud' counts as development, so I authorize deletion if this is voted offtopic.
Your server is irrelevant and nothing you set or change on it will affect client(s).
You don't tell us which AWS load balancer you use but to be at HTTPS level it must be Application or Classic, and in either case to do HTTPS it must terminate the SSL/TLS protocol -- in other words, the LB establishes one SSL/TLS connection with the client and decrypts the incoming request, parses it, and then optionally uses a separate SSL/TLS connection to the backend to re-encrypt, and reverses the process on the response: decrypt from the backend if necessary and re-encrypt to the client. See the line "SSL Offloading" well down in the table on that page; that's a jargon way of saying "LB does the SSL/TLS for the client, your server does not".
Thus the settings in the LB, only, control the SSL/TLS seen by the client(s). ELBSecurityPolicy-2016-08 which is the default (and I'm guessing that might be why you used it) excludes all DHE-RSA ciphersuites. (To avoid confusion, note the AWS webpage uses the OpenSSL names for ciphersuites, where RSA-only keyexchange is omitted from the name, whereas Zenmap/nmap uses the RFC names TLS_RSA_with_whatever.) It does allow ECDHE_ECDSA suites, but those will actually be negotiated, and thus seen by a scanner like Zenmap/nmap, only if you configure an ECDSA certificate and key -- which I bet you didn't.
Is there any documentation on what headers (specifically XFCC) the Istio Gateway might set when doing TLS termination with mutual TLS? Or does it not touch the headers?
Specifically referring to this section:
https://istio.io/docs/tasks/traffic-management/secure-ingress/#configure-a-mutual-tls-ingress-gateway
The following issue might be related to what I want, though it seems to be dealing more with east-west traffic and i'm more concerned with north-south:
https://github.com/istio/old_issues_repo/issues/165
Thanks!
I think Istio uses envoy to implement proxies so probably this is the proper documentation to look for headers, especially for XFCC:
https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#x-forwarded-client-cert
For the modification of headers, I've found the following issue, which I guess is not solved yet.
I begin learn the information protection and start from OpenSSL. But I read on the Wikipedia that SSL have trouble with security that still not solved and anyone must use TLS instead. Is it true? Is it mean that SSL now obsolete? (because there appears other way of information protection instead fixing SSL)
TLS is just the newer name for the protocol formerly named SSL. If you look at the protocol level you see that TLS 1.0 is practically SSL 3.1, TLS 1.1 is SSL 3.2 etc. Versions up to and including version SSL 3.0 are considered broken and should not be used any longer.
Because of this naming in practice "SSL" and "TLS" are often used to mean the same protocol group and often you find also "SSL/TLS" to refer to this protocol group. Usually only if a version number is added they refer to this version only. Libraries like OpenSSL, PolarSSL, MatrixSSL etc implement the protocol group, i.e. SSL and TLS.
To add to this naming confusion "SSL" is often used together with protocols like SMTP (send mail) or IMAP (access mail) to mean a secure connection from start while "TLS" is used in this context to mean secure connection after issuing a specific STARTTLS command. It is better to use "implicit" and "explicit" SSL/TLS instead.
SSL as a protocol is insecure, and TLS should be used instead. However, people often use the name 'SSL' to refer to SSL as well as TLS. Furthermore, it is often included in many systems as a fallback measure, so that connections can have some security, at least, if TLS isn't available. The merits of doing this are questionable, as some people feel that this allows developers to be lazy, or not even realize they're using an insecure method.
I'm new to JMS. I'm using ActiveMQ CPP (C++ version), but most probably my questions are language agnostic:
I saw that using didn't worked
failover:(tcp://N.N.N.N)?timeout=1000
while this works
failover://(tcp://N.N.N.N)?timeout=1000
When this change occurred and why?
According to TCP configuration, there's option connectionTimeout, but I don't see in a code. Do I miss something?
Connection options (e.g. connnection.closeTimeout) in case uri looks like failover:://(tc://N.N.N.N?a=b)?x=y should be applied to tcp or failover. Is there good link describing these options in depths?
Thanks
See the ActiveMQ-CPP URI configuration reference here:
http://activemq.apache.org/cms/configuring.html
There are some differences in the URI parsing between the C++, Java and .NET clients due to the available SDKs of each language.
Tim
www.fusesource.com
It seems that anyone can snoop on incoming/outgoing .NET web service SOAP messages just by dropping in a simple SoapExtension into the bin folder and then plumbing it in using:
<soapExtensionTypes>
<add type="MyLoggingSoapExtension, SoapLoggingTools" priority="0" group="High" />
<soapExtensionTypes>
Is there a way to prevent SOAP extensions from loading or to be asked in my app (through an event or some such mechanism) whether it's ok to load ?
#Hurst: thanks for the answer. I know about message level encryption/WS-Security and was hoping not to have to go that road. We have classic ASP clients using the service and that opens a small world of pain. There are SSL certs on the site running the web service but I was kinda hoping that I could discourage the client from tinkering with soap extensions as they have developers who have some ability to 'play'.
I am not sure what you mean by extensions and bin folders (I would guess you are using .NET), so I can't answer about them being loaded etc.
However, note that SOAP is designed to allow intermediaries to read the headers and even to modify them. (Do a search for "SOAP Active Intermediaries"). Judging by that, I expect there to be no reason for a technology to avoid snooping by preventing code from reading the SOAP.
The proper way to protect yourself is to use "message-level security". (This is in contrast to transport-level security, such as SSL, which does not protect from intermediaries). In other words, encrypt your own messages before sending.
One available standard used to implement message-level security mechanisms is the WS-Security protocol. This allows you to target the encryption to the payload and relevant headers regardless of transport. It is more complex, but that is how you would go about restricting access.
Totally agree with #Hurst - if you want to prevent others reading your messages you need to use message-level encryption. Otherwise even simple NetMon can crack over the wire traffic.
Of course if someone has access to the machine (given the access to /bin etc.), even cryptography may not be enough to prevent snoopers using debuggers e.g. to read in-memory representations of the message after decrypting.
With physical access to the machine - all bets are off.