webMethods

Hi team,

my customer uses wm9.12 and 10.15. and they want to use HTTPS as their secure protocol which in this case wM is the server side, and the client is called a browser.

this browser inserts a custom extension into the HTTPS header so it enriches the header on HTTPS, therefore wM will receive the header during the SSL handshake clienthello occurs.

the question, is it possible for wM to receive the extension value during the SSL Handshake and then the extension value is processed in flowservices?

This pic below as sample of extension which get by using debug SSL during Handshake.

https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/45eae3251567a97f90facb0a7b50a4847b91664c.jpeg 1.5x, https://higherlogicdownload.s3.amazonaws.com/IMWUC/webMethods/Files/45eae3251567a97f90facb0a7b50a4847b91664c.jpeg 2x" data-dominant-color="EDE8E8">

image507×586 109 KB

really appreciate your help!

Thanks,
Dimas

Hi Dimas,

can you explain the possible use case for this scenario, please?

Eventually, these parameters need to be placed in the HTTP Request header, which can be retrieved by using pub.flow:getTransportInfo as the first invocation in the flow service.

Regards,
Holger

Hi Holger,

I’ll share the details, of course.

Based on the image below, our customer has an MS/UE channel (imagine this as a browser) that accesses a website using HTTPS and sends a Client Hello packet to PGW-U. First PGW-U will identify the IP Address, server name (SNI), and protocol type. Second PGW-U will match the packet’s characteristics with its local configuration, Third PGW-U will enriching the header of the HTTPS Client Hello. This enriched HTTPS Header will later be sent to the web server (wM). and it will be visible in the Extension section when using Wireshark or in the wrapper.log (with SSL debug enabled).

The customer’s expectation for wM is that it should have the capability to read the header within the HTTPS Client Hello during the SSL Handshake between PGW-U and the web server (wM). This header should then be processed in flow services and returned to PGW-U as complete data.

The question is: Does wM have the capability as expected, i.e., to receive and process the header sent in the HTTPS Client Hello Packet?

image516×503 31.2 KB

This case is not the same as sending an HTTP request header, and it certainly cannot be retrieved using pub.flow:getTransportInfo.

Thanks,
Dimas

I must say that this is something I’ve never seen before. I’ll be doing some research to learn.

To the question @Holger_von_Thomsen asks – what is the specific purpose for extending the TLS information in this case? What is the client expecting Integration Server to do with it?

Based upon a quick review of RFC 3546 - Transport Layer Security (TLS) Extensions, extensions such as this would be the domain of the low-level components.

From IBM Documentation

“Extensions facilitates the addition of new features to the TLS protocol”

To help streamline the handshake when setting up the secure channel.

The JVM upon which IS runs would need to support extensions.

IMO, there is no circumstance in which TLS protocol data should processed in any way by FLOW services (or Java services). The TLS protocol is not intended for this purpose.

Hi reamon,

Thank you for the explanation.

The purpose of extending the TLS information by adding an Extension that includes the header in the Client Hello during the SSL Handshake is because PGW-U, which we know as the entity enriching the header, is an application that operates at the Network Level. Its capabilities do not support sending the typical payload header body to the web server (wM), so PGW-U has no choice to insertion the header fields into the HTTPS Client Hello packet.

What the client expects is to capture the extension containing the header that is sent through the HTTPS Client Hello Packet during the SSL handshake and then extract it so that it becomes a header, more or less like this:
{
“headers”: {
“x-msisdn”: “xxx”,
“x-imsi”: “xxxx”,
“x-forwarded”: “xxx”,
“x-user-location”: “xxx”
}
}"

As additional information, our customer previously had an internal discussion about whether to use an HTTP Header or an HTTPS Header, and the conclusion they reached was to use an HTTPS Header because the HTTP header was considered not secure enough, considering this data might be confidential to them.

Thanks,
Dimas

This statement infers that HTTP and HTTPS have different header definitions/semantics. They do not. “HTTPS” is simply shorthand for “HTTP over SSL” or “HTTP over TLS”. The headers are the same mechanism in both HTTP and HTTPS.

Likely you mean TLS header instead of HTTPS header.

The headers in TLS would not carry any “application” level information. Or shouldn’t. The only thing would be to confirm the identify of the client or streamline the handshake to establish the secure channel – this is where the “request client certificate” or “require client certificate” settings in wM IS along with certificate ID to username mapping to make sure the client is who they say they are.

If the expectation is the data in the TLS extension is to be part of the payload that IS FLOW services process, I think this is problematic.

The question remains – what specifically is IS expected to do with that data? So far the answer has been “capture”. What is the data and what will it be used for in the IS components? With that info, we may be able to suggest alternatives. Placing data in HTTP headers is fine as long as the communication is over TLS (commonly referred to as HTTPS).

Lastly, keep in mind that ClientHello, with its extensions, may still be sent in the clear depending upon the TLS version and extensions supported by both sides. Good-bye ESNI, hello ECH! has a great description of the evolution of TLS and the behaviors. Encrypted Client Hello - the last puzzle piece to privacy has additional info.

The assumption that sending TLS extensions in the clienthello message is “more secure” may be inaccurate. And I’m not sure TLS extensions are intended for “customers” to add arbitrary data elements to it.