On the subject of reversed proxies, did a quick scan across our customer and prospect base;
Of all CERTs/NCSCs we work with the vast majority has a proxy in front of their taxi server (especially when that server is embedded in a TIP
like ours)
Of all national security environments this is pretty much all architectures. Special note towards the use of API gateways here in addition
to reversed proxies.
Of all enterprises, just below half would use reversed proxies.
Of all taxi servers we host on behalf of our customers, we use a reverse proxy.
Hope that’s helpful input.
J-
From:
<> on behalf of Jason Keirstead <>
Date: Tuesday, 9 January 2018 at 13:17
To: John-Mark Gurney <>
Cc: "" <>
Subject: Re: [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL
The issue is it colliding *because* it is a mandatory path.
We define "/taxii" as a madatory path for TAXII 2, which means you can't use it for TAXII 1 (or anything else). So anyone who was already using "/taxii" for TAXII 1, can't implement TAXII 2 on the
same host/vhost. This can be a real problem for folks with products who can not make any use of VHost tricks to work around it.
-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: John-Mark Gurney <>
To: Jason Keirstead <>
Cc:
Date: 01/08/2018 09:30 PM
Subject: Re: [cti-taxii] TAXII 2 URLs and Mandatory Discovery URL
Jason Keirstead wrote this message on Wed, Jan 03, 2018 at 09:15 -0400:
> Hi everyone. I raised these concerns on Slack at the tail end of 2017, but
> thought i should send to the list as everyone has probably forgotten about
> them at this point.
>
> I am discovering some real implementation issues with TAXII 2 as it is
> defined today - namely around two things
>
> - The mandatory "/taxii" discovery root
Is this an issue w/ colliding? or just that there is a mandatory path?
The reason I asked, is that I voiced concern over this, and suggested
that we register, and use the .well-known RFC5785[1] mechanism, and
wonders if that would solve your problem?
> - The fact that we do not specify if URLs can be relative, or if they must
> be absolute.
Yes, this needs to be clarified, and looking at various web definitions
doesn't make it clear with out we use the various terms.
> The issue is, the spec is written around the idea that someone hosting a
> TAXII 2 server
>
> - Knows their host name and web root
> - Has full control over the root web server hosting TAXII
> - The /taxii endpoint does not already exist
Yes, this is a big problem w/ reverse proxies, which are common these
days...
> None of these things are going to be true for a lot of implementations,
> where one is trying to add TAXII 2 support to an already existing product.
>
>
> For (a) and (b), these provisions make it extremely difficult to implement
> a generic TAXII 2 support library vs. a full blown server. I have run into
> this myself trying to port the MITRE Medallion service to a library. If
> the library does not know where it is running, then it can't construct the
> full URLs the spec is expecting to be present in the discovery response
>
> For (c), If you have
https://urldefense.proofpoint.com/v2/url?u=https-3A__my-5Fapi-5Fgateway_taxii&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=9fBCbDJDV9Hq2aAJ9CHKi2xx_y0aMvVgH_msJcBjLCQ&s=S2PuT8me-kKvmULKNmsIVAP3lZ3fTaVD9prqlO5AqR8&e=
already
in use on your
> system for TAXII 1, then you actually can not implement TAXII 2 unless you
> make your TAXII 2 API run on a totally different VHost... something that
> is not always possible, *especially* for systems that are not registered
> in DNS and thus can't use VHost tricks.
Hmm... I thought that it was possible that you could run both at the same
time as there was not a collision of names under /taxii, but I could be
misremembering.
[1]
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5785&d=DwIBAg&c=jf_iaSHvJObTbx-siA1ZOg&r=k6Q07xZDujljzkKqZUfupXFUDIHGIiq-Sl_u1bw0hyA&m=9fBCbDJDV9Hq2aAJ9CHKi2xx_y0aMvVgH_msJcBjLCQ&s=Gban4ZMgCnh09viD_UllhwI1EHBvRR3R3yslO6n2apI&e=
--
John-Mark
