4:55 a.m.
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.
5:42 a.m.
Curl is what admins often use in their shell scripts .. I would at least continue
supporting it for read-access
6:58 a.m.
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
7:35 a.m.
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
8:59 a.m.
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
<darran.lofthouse(a)jboss.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
http://blog.arungupta.me
http://twitter.com/arungupta
9:36 a.m.
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
<darran.lofthouse(a)jboss.com> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:15 a.m.
+1 that we should keep curl support :-)
On Wed, Jan 8, 2014 at 6:36 AM, Darran Lofthouse
<darran.lofthouse(a)jboss.com> 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
> <darran.lofthouse(a)jboss.com> 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
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
--
http://blog.arungupta.me
http://twitter.com/arungupta
10:39 a.m.
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
12:01 p.m.
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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:25 p.m.
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
<darran.lofthouse(a)jboss.com> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3 p.m.
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 <darran.lofthouse(a)jboss.com>
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
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:19 p.m.
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 <darran.lofthouse(a)jboss.com>
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
>>> wildfly-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
3:54 p.m.
On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi(a)redhat.com> 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
4:24 p.m.
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 <jason.greene(a)redhat.com>:
On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:55 p.m.
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 <rodakr(a)gmx.ch> 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 <jason.greene(a)redhat.com>:
>
> On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi(a)redhat.com> 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
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
4:46 p.m.
On Jan 8, 2014, at 2:54 PM, Jason Greene <jason.greene(a)redhat.com> wrote:
On Jan 8, 2014, at 2:00 PM, Aleksandar Kostadinov <akostadi(a)redhat.com> 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
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
3758
days inactive
3758
days old
15 comments
9 participants
participants (9)
-
Aleksandar Kostadinov -
Arun Gupta -
Darran Lofthouse -
Heiko W.Rupp -
Jason Greene -
Jason Greene -
Ladislav Thon -
Radoslaw Rodak -
Thomas Segismont