Removing curl support from management HTTP

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing curl support from management HTTP

Darran Lofthouse
Hello all,

Just starting to plan some upstream changes for WildFly and just wanted
to gauge how much simple http tools like curl are in use?

If we were to completely disable their use would it cause problems?

Note: Where management messages are sent in using code to construct a
HTTP request this will still be possible with minor changes to the
message exchanges.

Regards,
Darran Lofthouse.
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Heiko W.Rupp
Curl is what admins often use in their shell scripts .. I would at least continue supporting it for read-access


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Ladislav Thon
In reply to this post by Darran Lofthouse
> Just starting to plan some upstream changes for WildFly and just wanted
> to gauge how much simple http tools like curl are in use?
>
> If we were to completely disable their use would it cause problems?

That would be a blocker regression for me :-)

Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).

LT
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Darran Lofthouse
Hello Ladislav,

No 'reasoning' as such at this point, and no decisions taken yet.  We
are currently discussing the future of domain management especially over
HTTP and I need to understand how important tools like this are.

We originally had support for standard HTTP clients on the requirements
list, just need to validate now if it was a valid requirement ;-)

Regards,
Darran Lofthouse.


On 08/01/14 11:58, Ladislav Thon wrote:

>> Just starting to plan some upstream changes for WildFly and just wanted
>> to gauge how much simple http tools like curl are in use?
>>
>> If we were to completely disable their use would it cause problems?
>
> That would be a blocker regression for me :-)
>
> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>
> LT
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Arun Gupta
I would agree with Heiko, Curl is often used by admins in their shell
scripts. This makes their scripts portable.

Is there an overhead to supporting curl ?

Arun

On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
<[hidden email]> wrote:

> Hello Ladislav,
>
> No 'reasoning' as such at this point, and no decisions taken yet.  We
> are currently discussing the future of domain management especially over
> HTTP and I need to understand how important tools like this are.
>
> We originally had support for standard HTTP clients on the requirements
> list, just need to validate now if it was a valid requirement ;-)
>
> Regards,
> Darran Lofthouse.
>
>
> On 08/01/14 11:58, Ladislav Thon wrote:
>>> Just starting to plan some upstream changes for WildFly and just wanted
>>> to gauge how much simple http tools like curl are in use?
>>>
>>> If we were to completely disable their use would it cause problems?
>>
>> That would be a blocker regression for me :-)
>>
>> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>>
>> LT
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
http://blog.arungupta.me
http://twitter.com/arungupta
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Darran Lofthouse
On 08/01/14 13:59, Arun Gupta wrote:
> I would agree with Heiko, Curl is often used by admins in their shell
> scripts. This makes their scripts portable.
>
> Is there an overhead to supporting curl ?

Not necessarily, new features are being discussed regarding
authentication at this point I am just trying to confirm if my
perception that users are using tools like curl is actually true ;-)

>
> Arun
>
> On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
> <[hidden email]> wrote:
>> Hello Ladislav,
>>
>> No 'reasoning' as such at this point, and no decisions taken yet.  We
>> are currently discussing the future of domain management especially over
>> HTTP and I need to understand how important tools like this are.
>>
>> We originally had support for standard HTTP clients on the requirements
>> list, just need to validate now if it was a valid requirement ;-)
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 08/01/14 11:58, Ladislav Thon wrote:
>>>> Just starting to plan some upstream changes for WildFly and just wanted
>>>> to gauge how much simple http tools like curl are in use?
>>>>
>>>> If we were to completely disable their use would it cause problems?
>>>
>>> That would be a blocker regression for me :-)
>>>
>>> Could you share what's the reasoning behind this? I use curl basically for everything that supports HTTP interaction (unless I build a specialized tool, but even then, I use curl for debugging the tool. It's immensely useful and I would hate losing it).
>>>
>>> LT
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Arun Gupta
+1 that we should keep curl support :-)

On Wed, Jan 8, 2014 at 6:36 AM, Darran Lofthouse
<[hidden email]> wrote:

> On 08/01/14 13:59, Arun Gupta wrote:
>>
>> I would agree with Heiko, Curl is often used by admins in their shell
>> scripts. This makes their scripts portable.
>>
>> Is there an overhead to supporting curl ?
>
>
> Not necessarily, new features are being discussed regarding authentication
> at this point I am just trying to confirm if my perception that users are
> using tools like curl is actually true ;-)
>
>
>>
>> Arun
>>
>> On Wed, Jan 8, 2014 at 4:35 AM, Darran Lofthouse
>> <[hidden email]> wrote:
>>>
>>> Hello Ladislav,
>>>
>>> No 'reasoning' as such at this point, and no decisions taken yet.  We
>>> are currently discussing the future of domain management especially over
>>> HTTP and I need to understand how important tools like this are.
>>>
>>> We originally had support for standard HTTP clients on the requirements
>>> list, just need to validate now if it was a valid requirement ;-)
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On 08/01/14 11:58, Ladislav Thon wrote:
>>>>>
>>>>> Just starting to plan some upstream changes for WildFly and just wanted
>>>>> to gauge how much simple http tools like curl are in use?
>>>>>
>>>>> If we were to completely disable their use would it cause problems?
>>>>
>>>>
>>>> That would be a blocker regression for me :-)
>>>>
>>>> Could you share what's the reasoning behind this? I use curl basically
>>>> for everything that supports HTTP interaction (unless I build a specialized
>>>> tool, but even then, I use curl for debugging the tool. It's immensely
>>>> useful and I would hate losing it).
>>>>
>>>> LT
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>



--
http://blog.arungupta.me
http://twitter.com/arungupta
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Thomas Segismont
In reply to this post by Darran Lofthouse
Le 08/01/2014 15:36, Darran Lofthouse a écrit :
> Not necessarily, new features are being discussed regarding
> authentication at this point I am just trying to confirm if my
> perception that users are using tools like curl is actually true ;-)

Sorry this is maybe a stupid question but what do you mean by "curl
support"? Is there anything special done when the HTTP client is curl?

Thomas

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Darran Lofthouse


On 08/01/14 15:39, Thomas Segismont wrote:
> Le 08/01/2014 15:36, Darran Lofthouse a écrit :
>> Not necessarily, new features are being discussed regarding
>> authentication at this point I am just trying to confirm if my
>> perception that users are using tools like curl is actually true ;-)
>
> Sorry this is maybe a stupid question but what do you mean by "curl
> support"? Is there anything special done when the HTTP client is curl?

As it stands today as we are only using the standard HTTP authentication
mechanisms there is nothing special other than maybe a --digest argument
to make a call using curl.

>
> Thomas
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Jason T. Greene
So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.

We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.

Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.

> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <[hidden email]> wrote:
>
>
>
>> On 08/01/14 15:39, Thomas Segismont wrote:
>> Le 08/01/2014 15:36, Darran Lofthouse a écrit :
>>> Not necessarily, new features are being discussed regarding
>>> authentication at this point I am just trying to confirm if my
>>> perception that users are using tools like curl is actually true ;-)
>>
>> Sorry this is maybe a stupid question but what do you mean by "curl
>> support"? Is there anything special done when the HTTP client is curl?
>
> As it stands today as we are only using the standard HTTP authentication
> mechanisms there is nothing special other than maybe a --digest argument
> to make a call using curl.
>
>>
>> Thomas
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Aleksandar Kostadinov
I'm not sure what other auth mechanism you are talking about. There
might be something new and very elaborated.

But the problem with non-encrypted connections is that any hash could be
used without the need to recover the plain text password. With cookies,
one can sniff and use them.
Yes, it is somehow worse to steal the plaintext password but at the end
do benefits outweight the inconvenience and effort?

Jason Greene wrote, On 01/08/2014 07:25 PM (EEST):

> So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.
>
> We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.
>
> Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.
>
>> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <[hidden email]> wrote:
>>
>>
>>
>>> On 08/01/14 15:39, Thomas Segismont wrote:
>>> Le 08/01/2014 15:36, Darran Lofthouse a écrit :
>>>> Not necessarily, new features are being discussed regarding
>>>> authentication at this point I am just trying to confirm if my
>>>> perception that users are using tools like curl is actually true ;-)
>>>
>>> Sorry this is maybe a stupid question but what do you mean by "curl
>>> support"? Is there anything special done when the HTTP client is curl?
>>
>> As it stands today as we are only using the standard HTTP authentication
>> mechanisms there is nothing special other than maybe a --digest argument
>> to make a call using curl.
>>
>>>
>>> Thomas
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Darran Lofthouse


On 08/01/14 20:00, Aleksandar Kostadinov wrote:
> I'm not sure what other auth mechanism you are talking about. There
> might be something new and very elaborated.
>
> But the problem with non-encrypted connections is that any hash could be
> used without the need to recover the plain text password.

They still need to go through the trouble of processing the hash to
discover the password used to create the hash.

However I will start some threads later on the actual changes, all I am
looking for at the moment is to verify how widely tools like curl are
currently used to confirm if we need to spend time considering them.

> With cookies,
> one can sniff and use them.
> Yes, it is somehow worse to steal the plaintext password but at the end
> do benefits outweight the inconvenience and effort?
>
> Jason Greene wrote, On 01/08/2014 07:25 PM (EEST):
>> So the big problem is that http digest has not been updated to use stronger  crypto hash. There is a proposed RFC but no one has implemented it.
>>
>> We could implement it and contribute that to curl as well but I suspect we still need standard digest compatibility until most OS's have caught up with that version of curl.
>>
>> Alternatively we could move to SSL by default, and switch to plain with scrypt and solve the various challenges there.
>>
>>> On Jan 8, 2014, at 11:02 AM, Darran Lofthouse <[hidden email]> wrote:
>>>
>>>
>>>
>>>> On 08/01/14 15:39, Thomas Segismont wrote:
>>>> Le 08/01/2014 15:36, Darran Lofthouse a écrit :
>>>>> Not necessarily, new features are being discussed regarding
>>>>> authentication at this point I am just trying to confirm if my
>>>>> perception that users are using tools like curl is actually true ;-)
>>>>
>>>> Sorry this is maybe a stupid question but what do you mean by "curl
>>>> support"? Is there anything special done when the HTTP client is curl?
>>>
>>> As it stands today as we are only using the standard HTTP authentication
>>> mechanisms there is nothing special other than maybe a --digest argument
>>> to make a call using curl.
>>>
>>>>
>>>> Thomas
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

jtgreene
Administrator
In reply to this post by Aleksandar Kostadinov

On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <[hidden email]> wrote:

> I'm not sure what other auth mechanism you are talking about. There
> might be something new and very elaborated.

Just a SHA based digest vs an MD5 one

>
> But the problem with non-encrypted connections is that any hash could be
> used without the need to recover the plain text password. With cookies,
> one can sniff and use them.

That’s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can’t be replayed.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

Radoslaw Rodak
Hi

It starts to be interesting :-)
Whats about hash length extension attack...

https://blog.whitehatsec.com/hash-length-extension-attacks/

Cheers Radek


Am 08.01.2014 um 21:54 schrieb Jason Greene <[hidden email]>:

>
> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <[hidden email]> wrote:
>
>> I'm not sure what other auth mechanism you are talking about. There
>> might be something new and very elaborated.
>
> Just a SHA based digest vs an MD5 one
>
>>
>> But the problem with non-encrypted connections is that any hash could be
>> used without the need to recover the plain text password. With cookies,
>> one can sniff and use them.
>
> That’s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can’t be replayed.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

jtgreene
Administrator
In reply to this post by jtgreene

On Jan 8, 2014, at 2:54 PM, Jason Greene <[hidden email]> wrote:

>
> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <[hidden email]> wrote:
>
>> I'm not sure what other auth mechanism you are talking about. There
>> might be something new and very elaborated.
>
> Just a SHA based digest vs an MD5 one

https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/?include_text=1

It’s in draft state which is why no one has implemented it yet.

>
>>
>> But the problem with non-encrypted connections is that any hash could be
>> used without the need to recover the plain text password. With cookies,
>> one can sniff and use them.
>
> That’s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can’t be replayed.
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Removing curl support from management HTTP

jtgreene
Administrator
In reply to this post by Radoslaw Rodak
That’s an attack against a signature where you know the content and the length of the secret. In a challenge response protocol this information is not known.

On Jan 8, 2014, at 3:24 PM, Radoslaw Rodak <[hidden email]> wrote:

> Hi
>
> It starts to be interesting :-)
> Whats about hash length extension attack...
>
> https://blog.whitehatsec.com/hash-length-extension-attacks/
>
> Cheers Radek
>
>
> Am 08.01.2014 um 21:54 schrieb Jason Greene <[hidden email]>:
>
>>
>> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <[hidden email]> wrote:
>>
>>> I'm not sure what other auth mechanism you are talking about. There
>>> might be something new and very elaborated.
>>
>> Just a SHA based digest vs an MD5 one
>>
>>>
>>> But the problem with non-encrypted connections is that any hash could be
>>> used without the need to recover the plain text password. With cookies,
>>> one can sniff and use them.
>>
>> That’s not true. Digest is a challenge response protocol that uses a nonce as part of the sent hash. A packet sniffed hash can’t be replayed.
>>
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev