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.
Related
There is good documentation (OpenTelemetry project, W3C) on generating, passing, and parsing distributed tracing headers (e.g., traceparent) on the server side, however I have not found anything authoritative on exposing trace IDs to the client side. E.g., I would like to configure my clients to use the trace ID from an error response to add context to a Sentry log, or allow users to include this information in a support request.
Google Cloud seems to add X-Cloud-Trace-Context to responses on at least Cloud Run services... but it's not documented and might not be intentional but present only as a convenient bug.
Is there a standard or even a broadly-used convention for this, or is this entirely up to implementations to fashion on their own?
I understand you can use istio to open a circuit breaker when service isn't responding. Instead of return back a 503, is it possible to redirect to a different URL? Same question but when the original service returns back a 500, can we redirect to another URL?
Or is it possible to have offline mode response provided by istio? I assume the easiest way to do this through URL redirection to a offline mode service URL, but open to ideas...
can we redirect to another URL?
If I understand correctly you're asking if it's possible to do that just with istio.
According to documentation
While Istio failure recovery features improve the reliability and availability of services in the mesh, applications must handle the failure or errors and take appropriate fallback actions. For example, when all instances in a load balancing pool have failed, Envoy returns an HTTP 503 code. The application must implement any fallback logic needed to handle the HTTP 503 error code.
And dzone.com, Christian Posta blog post:
Istio improves the reliability and availability of services in the mesh. However, applications need to handle the errors and take appropriate fallback actions. For example, when all instances in a load balancing pool have failed, Envoy will return HTTP 503. It is the responsibility of the application to implement any fallback logic that is needed to handle the HTTP 503 error code from an upstream service.
With a service mesh, at the moment without specialized libraries for failure context propagation, the failure reasons are more opaque. This doesn’t mean our application cannot take fallbacks (for both transport and client-specific errors). I’d argue it’s very important for the protocol of any application, whether using library-specific frameworks OR NOT) to always adhere to the promises it’s trying to keep for its clients. If it finds that it cannot complete its intended action, it should figure a way to gracefully degrade. Luckily, you don’t need application-specific frameworks for this. Most languages have built-in error and exception trapping and handling. Fallbacks should be implemented in these exception paths.
Sadly the answer is no, you can't. You would've to implement that in your application.
Additional resources:
demystifying istio circuit breaking
istio circuit breaker when failure is an option
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 am trying to come up with a way to expose the specific build number of a web service (REST and SOAP interfaces) using HTTP in response to messages.
Just to be clear I am not trying to control which version of an application is being used by a client as this is handled by the traffic manager and service registry (also much discussed already), I only want to be able to debug later what version was used or is being used, e.g., to check the traffic manager is serving up the correct version.
I have spent a long time looking at the HTTP spec and can't decide between using Pragma
Pragma: application-version=1.0.0-SNAPSHOT
using an additional Server header
Server: Apache-Coyote/1.1
Server: MyService-1.0.0-SNAPSHOT
using a Via
Via: MyService-1.0.0-SNAPSHOT
or a customer header
X-ApplicationVersion: 1.0.0-SNAPSHOT
To my mind using a Via or a Server is semantically incorrect but using an X- header bears the risk of being dropped by proxies but Pragma is unconstrained and thus more difficult to parse if wanted to use it programmatically.
I also have a feeling that multiple Server headers won't be respected but there is no way to specify multiple values with the container I'm using (JBoss).
Is there any precedent for this?
Anyone have any tips?
Should I just shut up and use one?
To my mind using a Via or a Server is semantically incorrect but using
an X- header bears the risk of being dropped by proxies
I would not worry too much about the X headers being dropped. Take this call to the ebay finding service for example
http://svcs.ebay.com/services/search/FindingService/v1?OPERATION-NAME=findItemsByKeywords&SERVICE-VERSION=1.0.0&RESPONSE-DATA-FORMAT=XML&REST-PAYLOAD&keywords=harry%20potter
The response includes this header.
X-EBAY-SOA-SERVICE-VERSION: 1.12.0
I've seen the X headers used quite a lot for this purpose.
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.