[slscripters] issues with llRequestSecureURL

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

[slscripters] issues with llRequestSecureURL

Marc Adored
Hey guys when I use llRequestSecureURL and I go to the url in my browser I get this error: http://cl.ly/UCAz

But when I just use llRequestURL the "Hello World!" comes up fine.


Unmodified outside of switching back and forth between secure and not secure for testing.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] issues with llRequestSecureURL

Darien Caldwell-2
The problem is  your browser. That message is coming from Chrome. If you use the internal viewer browser, you'll see it works.

The problem that Chrome perceives is, that the security certificates is self-signed. it's not from a recognized authority. This is common for randomly generated URLs.  Chrome (and other browsers) will flag it as a security precaution.

But since HTTP-IN is meant for inworld to inworld communication, or inworld to outside *server* communication, it's not really a problem. HTTP-IN isn't meant for serving web pages to browsers directly, more or less.

              - Dari


On Sat, Mar 1, 2014 at 12:44 PM, Marc Adored <[hidden email]> wrote:
Hey guys when I use llRequestSecureURL and I go to the url in my browser I get this error: http://cl.ly/UCAz

But when I just use llRequestURL the "Hello World!" comes up fine.


Unmodified outside of switching back and forth between secure and not secure for testing.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] issues with llRequestSecureURL

Marc Adored
Well its not an issue with Chrome just to correct that :-) Its because its a self signed certificate and not signed by an authoritative source. I deal with SSL certificates in my line of work.

Also the cert doesn't just work on inworld to outworld servers. You have to set your programming language to ignore the fact that it is a cert that is not signed by an authoritative source. Man in the middle attacks can happen this way and completely breaks the main reason for using SSL.

They could easily buy a $100 wild card certificate and use that for the *.secondlife.com sub domains. It will validate everywhere as it will be signed by an authoritative source.

I was hoping that this was just a temporary issue but it looks like its the way it is actually supposed to work. I found an old ticket about it but its closed as wont finish :( https://jira.secondlife.com/browse/SVC-3240




On Sat, Mar 1, 2014 at 5:29 PM, Darien Caldwell <[hidden email]> wrote:
The problem is  your browser. That message is coming from Chrome. If you use the internal viewer browser, you'll see it works.

The problem that Chrome perceives is, that the security certificates is self-signed. it's not from a recognized authority. This is common for randomly generated URLs.  Chrome (and other browsers) will flag it as a security precaution.

But since HTTP-IN is meant for inworld to inworld communication, or inworld to outside *server* communication, it's not really a problem. HTTP-IN isn't meant for serving web pages to browsers directly, more or less.

              - Dari


On Sat, Mar 1, 2014 at 12:44 PM, Marc Adored <[hidden email]> wrote:
Hey guys when I use llRequestSecureURL and I go to the url in my browser I get this error: http://cl.ly/UCAz

But when I just use llRequestURL the "Hello World!" comes up fine.


Unmodified outside of switching back and forth between secure and not secure for testing.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] issues with llRequestSecureURL

Darien Caldwell-2
I understand what you're saying, but as long as the Cert is generated by the service you're accessing, it's technically valid. The point of SSL is to encrypt the data, not verify the source. It's up to you know who you're connecting to

People always use Man in the Middle as an argument, when in reality it's very rare and hard to pull off. Especially when the URL you are accessing is generated on the fly. If someone is able to get between you and your Agni URL that fast, you're already pre-compromised to begin with.

      - Dari


On Sat, Mar 1, 2014 at 4:41 PM, Marc Adored <[hidden email]> wrote:
Well its not an issue with Chrome just to correct that :-) Its because its a self signed certificate and not signed by an authoritative source. I deal with SSL certificates in my line of work.

Also the cert doesn't just work on inworld to outworld servers. You have to set your programming language to ignore the fact that it is a cert that is not signed by an authoritative source. Man in the middle attacks can happen this way and completely breaks the main reason for using SSL.

They could easily buy a $100 wild card certificate and use that for the *.secondlife.com sub domains. It will validate everywhere as it will be signed by an authoritative source.

I was hoping that this was just a temporary issue but it looks like its the way it is actually supposed to work. I found an old ticket about it but its closed as wont finish :( https://jira.secondlife.com/browse/SVC-3240




On Sat, Mar 1, 2014 at 5:29 PM, Darien Caldwell <[hidden email]> wrote:
The problem is  your browser. That message is coming from Chrome. If you use the internal viewer browser, you'll see it works.

The problem that Chrome perceives is, that the security certificates is self-signed. it's not from a recognized authority. This is common for randomly generated URLs.  Chrome (and other browsers) will flag it as a security precaution.

But since HTTP-IN is meant for inworld to inworld communication, or inworld to outside *server* communication, it's not really a problem. HTTP-IN isn't meant for serving web pages to browsers directly, more or less.

              - Dari


On Sat, Mar 1, 2014 at 12:44 PM, Marc Adored <[hidden email]> wrote:
Hey guys when I use llRequestSecureURL and I go to the url in my browser I get this error: http://cl.ly/UCAz

But when I just use llRequestURL the "Hello World!" comes up fine.


Unmodified outside of switching back and forth between secure and not secure for testing.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters




_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
Reply | Threaded
Open this post in threaded view
|

Re: [slscripters] issues with llRequestSecureURL

Corvan Nansen
The problem is, unless the certificate has a signing chain that’s rooted in a Trusted Root CA, you can’t be sure that the cert was generated by the service it claims to have been generated for. I can easily generate a self-signed certificate that claims to be for sim1459.agni.secondlife.com, but no one should trust it, and by default most browsers will at least flag the connection attempt to indicate that the cert is not trusted. “as long as the Cert is generated by the service you’re accessing”… how can you be sure that’s the case if you don’t have a signature chain back to a trusted root? Answer: You really don’t.

Even on-the-fly URLs are vulnerable to DNS Spoofing attacks, so when you look up sim1459.agni.secondlife.com you get the IP address of the attacker’s machine rather than the sim you’re attempting to connect to. Granted, these attacks aren’t particularly common, but until we get SecureDNS or equivalent in widespread use around the Internet, they are both possible and increasing in frequency.

I’ll echo Marc’s sentiment that it would behoove LL to buy a signing cert of their own and then install validly signed certs on the sim servers. It’s cheap and easy to do.

Cheers,
Corvan


On Mar 1, 2014, at 5:08 PM, Darien Caldwell <[hidden email]> wrote:

I understand what you're saying, but as long as the Cert is generated by the service you're accessing, it's technically valid. The point of SSL is to encrypt the data, not verify the source. It's up to you know who you're connecting to

People always use Man in the Middle as an argument, when in reality it's very rare and hard to pull off. Especially when the URL you are accessing is generated on the fly. If someone is able to get between you and your Agni URL that fast, you're already pre-compromised to begin with.

      - Dari


On Sat, Mar 1, 2014 at 4:41 PM, Marc Adored <[hidden email]> wrote:
Well its not an issue with Chrome just to correct that :-) Its because its a self signed certificate and not signed by an authoritative source. I deal with SSL certificates in my line of work.

Also the cert doesn't just work on inworld to outworld servers. You have to set your programming language to ignore the fact that it is a cert that is not signed by an authoritative source. Man in the middle attacks can happen this way and completely breaks the main reason for using SSL.

They could easily buy a $100 wild card certificate and use that for the *.secondlife.com sub domains. It will validate everywhere as it will be signed by an authoritative source.

I was hoping that this was just a temporary issue but it looks like its the way it is actually supposed to work. I found an old ticket about it but its closed as wont finish :( https://jira.secondlife.com/browse/SVC-3240




On Sat, Mar 1, 2014 at 5:29 PM, Darien Caldwell <[hidden email]> wrote:
The problem is  your browser. That message is coming from Chrome. If you use the internal viewer browser, you'll see it works.

The problem that Chrome perceives is, that the security certificates is self-signed. it's not from a recognized authority. This is common for randomly generated URLs.  Chrome (and other browsers) will flag it as a security precaution.

But since HTTP-IN is meant for inworld to inworld communication, or inworld to outside *server* communication, it's not really a problem. HTTP-IN isn't meant for serving web pages to browsers directly, more or less.

              - Dari


On Sat, Mar 1, 2014 at 12:44 PM, Marc Adored <[hidden email]> wrote:
Hey guys when I use llRequestSecureURL and I go to the url in my browser I get this error: http://cl.ly/UCAz

But when I just use llRequestURL the "Hello World!" comes up fine.


Unmodified outside of switching back and forth between secure and not secure for testing.

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters



_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters


_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters