OASIS Open Mailing List Archives  ·  All Lists  ·  cti-taxii  ·  2018-01

cti-taxii — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

TAXII 2 URLs and Mandatory Discovery URL


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: <[email protected]> on behalf of Jason Keirstead <[email protected]> Date: Tuesday, 9 January 2018 at 13:17 To: John-Mark Gurney <[email protected]> Cc: "[email protected]" <[email protected]> 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 <[email protected]> To:         Jason Keirstead <[email protected]> Cc:         [email protected] 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

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]