I posted a comment to the blog post. The thing that keeps getting dodged is the fact that I see consessions made for other security issues that don't seem to be getting made for sockets. If a user makes an explicit action, and then specifically approves
opening the port, that's about as much security as you get on the desktop.
While I don't agree that "just because Adobe leaves the hole open means you should", there are ways around the issue. I mention group policy in my comment in regards to ports, but I think there needs to be a lot more configurable about Silverlight when
it comes to group policy, step up above and beyond Adobe and make Silverlight corporate friendly, being able to enforce things like full screen, local storage, what sites can run SL apps, cross domain, ports, etc from an administrative prespective would earn
you a lot of clout when it comes to convincing IT to use SL for LoB apps.
I am starting to think the missing part of this story is this:
it's Microsoft, and they have been raked over the coals in the past for not having good security, for leaving holes... they have been sued and ridiculed so much that perhaps now they have chosen to be uber-careful on this issue and want to be 1001% sure
that the world at large has to say "ok this is different, they made it secure and safe to use"
I can see that as a possiible bottom line from inside HQ's thinking on this...
Not a chance. If Microsoft's worry were really about getting blamed for creating security holes in the fabric of the Internet, they would implement security exactly as Adobe has done. That way, if anybody attempted to point fingers, Microsoft could point
out that they had followed industry best practices and accepted standards. Deviating from Flash's implementation holds more danger from a legal perspective.
I am starting to think the missing part of this story is this:
it's Microsoft, and they have been raked over the coals in the past for not having good security, for leaving holes... they have been sued and ridiculed so much that perhaps now they have chosen to be uber-careful on this issue and want to be 1001% sure
that the world at large has to say "ok this is different, they made it secure and safe to use"
I can see that as a possiible bottom line from inside HQ's thinking on this...
Not a chance. If Microsoft's worry were really about getting blamed for creating security holes in the fabric of the Internet, they would implement security exactly as Adobe has done. That way, if anybody attempted to point fingers, Microsoft could point
out that they had followed industry best practices and accepted standards. Deviating from Flash's implementation holds more danger from a legal perspective.
I don't think that works at all.... the claim from msft is that what they have done is better (security wise) than what flash has.
that aside if it went to court beeing "the same as the other guy" is not a defense and would only provide more ammo for the other side to say things about them.
but this is at best totaly guessing on both sides.....i am not a lawyer, are you?
and i did not say "Microsoft's worry were really about getting blamed for creating security holes in the fabric of the Internet"
just a possible flaw in the slilverlight runtime; hardly the same as hole in the internet...
I run a server on port 80 outside of traditional web services. I can connect to this port via sockets in Flash or Java 1.6. Now I don't care about the FTP port or mail ports etc. Port 80 is the most important and the least likely to be blocked. Sockets can
be prevented from being used by various proxies. In this case I simply connect via HTTP to my server and all is good. Since SilverLight allows cross-domain for HTTP it will work in this case as well.
Sockets are just more efficient. Also all browsers place limitations on the number of HTTP connections you can have. These are used for images, and whatever. Most browsers today allow over 6 HTTP connections but 2 HTTP connections can be imposed.
Now it is not earth shaking if I also have to listen on 4502 or whatever the SilverLight ports are but these are more likely to be blocked by corporations so then I have to default to the less efficient and probamatic HTTP connection.
When I connect via sockets in Flash or Java, I can just send the policy file over the same port I am connecting on. This is done underneath and it is not necessary to also listen on another policy port.
So in SilverLight I also have to listen on port 953 I believe and deliver the policy on that port. At the very least Microsoft should allow the policy to be delivered in the same way as Flash or Java do. That is, when I connect via sockets on any port, an
initial connection is made underneath on the same port to get the policy and then the normal connection goes thru. One problem I see here is that Java, Flash, and SliverLight require different policy formats so the policy request needs to identify itself as
being Flash, Java, or SilverLight so this seems a problem where in the policy port senario, it identifies with SilverLight or flash. But this is just bad planning as we have come to expect these days. Now we can just listen on ports 853, 953, 80, 4502 and
whatever other pulled out of a hat port someone else comes up with.
I of course also want MS to open up port 80 for sockets. It is safe with the proper policy in place. MS you already have cross-domain for HTTP connections.
Please again note for Java, Flash, and SilverLight: Policy request need to identify themselves so that the proper policy file can be delivered. In this day you just cannot depend on one service or another being available, so good to support them all.
GuinnessKMF
Member
222 Points
58 Posts
Re: Re: Lacking arbitrary socket support
Jun 26, 2009 03:13 PM | LINK
I posted a comment to the blog post. The thing that keeps getting dodged is the fact that I see consessions made for other security issues that don't seem to be getting made for sockets. If a user makes an explicit action, and then specifically approves opening the port, that's about as much security as you get on the desktop.
While I don't agree that "just because Adobe leaves the hole open means you should", there are ways around the issue. I mention group policy in my comment in regards to ports, but I think there needs to be a lot more configurable about Silverlight when it comes to group policy, step up above and beyond Adobe and make Silverlight corporate friendly, being able to enforce things like full screen, local storage, what sites can run SL apps, cross domain, ports, etc from an administrative prespective would earn you a lot of clout when it comes to convincing IT to use SL for LoB apps.
andulvar
Member
181 Points
129 Posts
Re: Lacking arbitrary socket support
Jun 29, 2009 09:45 PM | LINK
Not a chance. If Microsoft's worry were really about getting blamed for creating security holes in the fabric of the Internet, they would implement security exactly as Adobe has done. That way, if anybody attempted to point fingers, Microsoft could point out that they had followed industry best practices and accepted standards. Deviating from Flash's implementation holds more danger from a legal perspective.
figuerres
Participant
1312 Points
355 Posts
Re: Lacking arbitrary socket support
Jun 29, 2009 10:15 PM | LINK
I don't think that works at all.... the claim from msft is that what they have done is better (security wise) than what flash has.
that aside if it went to court beeing "the same as the other guy" is not a defense and would only provide more ammo for the other side to say things about them.
but this is at best totaly guessing on both sides.....i am not a lawyer, are you?
and i did not say "Microsoft's worry were really about getting blamed for creating security holes in the fabric of the Internet"
just a possible flaw in the slilverlight runtime; hardly the same as hole in the internet...
DonMoir
Member
8 Points
4 Posts
Re: Lacking arbitrary socket support
Jun 30, 2009 03:45 PM | LINK
Just a few points:
I run a server on port 80 outside of traditional web services. I can connect to this port via sockets in Flash or Java 1.6. Now I don't care about the FTP port or mail ports etc. Port 80 is the most important and the least likely to be blocked. Sockets can be prevented from being used by various proxies. In this case I simply connect via HTTP to my server and all is good. Since SilverLight allows cross-domain for HTTP it will work in this case as well.
Sockets are just more efficient. Also all browsers place limitations on the number of HTTP connections you can have. These are used for images, and whatever. Most browsers today allow over 6 HTTP connections but 2 HTTP connections can be imposed.
Now it is not earth shaking if I also have to listen on 4502 or whatever the SilverLight ports are but these are more likely to be blocked by corporations so then I have to default to the less efficient and probamatic HTTP connection.
When I connect via sockets in Flash or Java, I can just send the policy file over the same port I am connecting on. This is done underneath and it is not necessary to also listen on another policy port.
So in SilverLight I also have to listen on port 953 I believe and deliver the policy on that port. At the very least Microsoft should allow the policy to be delivered in the same way as Flash or Java do. That is, when I connect via sockets on any port, an initial connection is made underneath on the same port to get the policy and then the normal connection goes thru. One problem I see here is that Java, Flash, and SliverLight require different policy formats so the policy request needs to identify itself as being Flash, Java, or SilverLight so this seems a problem where in the policy port senario, it identifies with SilverLight or flash. But this is just bad planning as we have come to expect these days. Now we can just listen on ports 853, 953, 80, 4502 and whatever other pulled out of a hat port someone else comes up with.
I of course also want MS to open up port 80 for sockets. It is safe with the proper policy in place. MS you already have cross-domain for HTTP connections.
Please again note for Java, Flash, and SilverLight: Policy request need to identify themselves so that the proper policy file can be delivered. In this day you just cannot depend on one service or another being available, so good to support them all.
Don