I have C# code that uploads a file to an FTP server. Now TLS 1.2 is used and I adapted the code for this, but there is still a problem with TLS session resumption.
According to this link Microsoft plugged a TLS hole by disabling the resume by an update in 2019. To let it work they describe that “Extend Master Secret” should be used. As far I could search this is the exchange of some keys between client and server to guarantee the client did not change.
But exactly how do you implement this in C#, does anyone have an example of this or can refer to some documentation ?
Your help is highly appreceated
Related
Could any one instruct me the steps of implementing Encrypted Media Extensions using videojs-contrib-eme in local server (with Access Point) which doesn't has internet.
Users connect to local server using WiFi with mobile and playback the videos in browser.
So my question is as
EME implementations use the following external components:
Key System
Content Decryption Module (CDM):
License (Key) server
Packaging service
(refer for more info -- https://developers.google.com/web/fundamentals/media/eme)
what components are already provided by videojs-contrib-eme , and what components do I need to implement ?
It sounds like you are building for an off-line case - the main DRM's supported by most browsers, Widevine, FairPlay and PlayReady, require an internet connection usually for the license request and response.
It is possible to have persistent licenses, i.e. a DRM license which will work offline for download and go use cases like watching movies offline, but even this requires internet connectivity for the original license request and response.
If you plan to implement your own proprietary DRM system, then you will need more changes than just to the player itself, i.e. video.js, in your example.
You will need to implement some form of key server, your own CDM and some form of packager.
It's certainly possible to do all this, but it is a lot of work. If this is not just for a learning exercise, it may be more practical to implement some simple encryption solution on your server and then add simple decryption functionality just before you play the content. This is not as secure but may be good enough for your needs.
Alternatively if you really want DRM level security, it might be worth seeing if you can have limited internet access just for the DRM license requests and responses which are typically very small. This would also you leverage standard browsers and packagers.
I am wondering if there is a good way of making automated system testing for a Chromecast receiver application?
If you open the application URL in a Chrome browser, the cast_receiver library cannot find the websocket connection on:
ws://localhost:8008/v2/ipc
Since this handles the communication between the app and the Chromecast hardware, I am thinking of something like a Node.js websocket server that can talk to the chromecast receiver app. Is there such a system, or do anyone know if there are plans of google releasing something for this kind of testing?
Also, would there be other problems related to the difference between the chromecast browser and chrome browser? As I understand, the chromecast browser is just a subset of chrome, which makes me think it should work.
No, there is no easy way to do this.
DISCLAIMER: I haven't tried any of what I'm about to suggest. It's also probably a terribly idea as Google could change the protocol any time and in any fashion they desire since it isn't a public thing.
BIG DISCLAIMER: You may be in violation of the ToS by doing this as Section 3.2 (Developer Policies) states that you "may not ... develop a standalone technology ... any functionality of any Google Cast Receiver". Possibly, you'd be making a standalone piece of technology that replicated the IPC functionality. But I don't know. I'm not a lawyer.
If you want to go and do this, I'd suggest making a copy of the Google Cast Receiver SDK (www.gstatic.com/cast/sdk/libs/receiver/2.0.0/cast_receiver.js as of April 28, 2015) and altering it so that it logs out the messages that are being sent and received.
Luckily, it appears that we have logging messages to help us find the relevant code.
The receiving method has the string "Received message". I would guess that "a.message" is what is being received.
The sending method has the string "IPC message sent". I would guess that "a" is what is being sent.
Once you've instrumented your copy of the code, you need to publish it somewhere that your receiver app can see it and then you need to edit your receiver app to point to your new and improved SDK. Please please please make sure that you do this on a non-published app for testing purposes only.
Once that is done, you need to find some way to get your messages out of the code and into something that you can access. You have a few options.
Fiddle around with the code more and figure out how to get the Chromecast to log out the data you want;
Store the information in an array and read it using the debugger;
Open your own socket (or websocket) and send that data to a server that you control.
From here, you can run your app, interact with it, and then have a complete record of the IPC messages that were sent and received. Armed with this, you can create your own Fake-IPC server that listens for specific messages and spits out the stuff that is in your log.
I am new to screen scraping. When i use proxy server and when i track the HTTP transactions, i am getting my post datas revealed to me. So my doubt/problem here is,
1)Will it get stored in the server side or it will be revealed only to the client side?
2)Do we have an option of encrypting the post data in screen scraping?
3)Is it advisable to use screen scraping for banking applications?
I am using screen scraper tool which i have downloaded it from
http://www.screen-scraper.com/download/choose_version.php. (Enterprise version)
Thanks in advance.
My experience with scraping is that if you aren't doing anything super complex (like logging into a secure website like an online banking website, etc.) then Python has some great libraries that will help you out a lot.
To answer your questions:
1) You may need to be more clear, but this really depends on your server/client architecture.
2) As a matter of fact you do. Urllib and Urllib2 (built-in Python libraries) both have functions that enable you to encrypt data before you make a POST. As far as how secure this encryption is, for most applications, this will suffice.
3) I actually have done scraping on online banking sites! I'm not exactly familiar with that tool, but I would recommend using something a little different than a scraper. Selenium, which is a "web-driver", allows you to simulate the use of a browser, meaning anything that the broswer does in the background in order to validate the session is automatically taken care of. The main problem I ran into while trying to scrape the banking site was the loss of important session data.
Selenium - https://pypi.python.org/pypi/selenium
Other libraries you may find useful are: urllib, urllib2, and Mechanize
I hope I was somewhat helpful!
I've used screen-scraper to scrape banking sites before. It will impact the site just like your browser--if the site uses encryption the connection from screen-scraper to the site will be too.
If you have a client page sending data to screen-scraper, you probably should encrypt that. I generally just make the connection via SSH.
1) What do you mean by server side? Your proxy server or screen-scraper software? Any of them can read/store your information.
2) If you are connecting through HTTPS then your software should warn you about malicious proxy server: https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server
3) I don't think they have some logger which they can read. But if you are concerned you can try to write your own. There are some APIs which you can read HTML easily with jQuery sintax:
https://pypi.python.org/pypi/pyquery or XPath: http://net.tutsplus.com/tutorials/javascript-ajax/web-scraping-with-node-js/
we are working on an ASP.NET project that is required to comply with the OWASP ASVS checklist. One of the term is "Verify that backend TLS connection failures are logged." I couldn't find a way to achieve this but the customer is holding us to it. Any suggestions/references? Sample code will be even better.
Here's the link to the owasp thing:
http://code.google.com/p/owasp-asvs/wiki/Verification_V10
Thanks in advance.
I agree this is badly worded. There is a revamp of the ASVS at the moment. Come on by and help us make things more concrete and testable.
In your instance, TLS connections are typically maintained by the operating system on behalf of application and library code that rarely if ever makes any real effort to vaidate that the TLS connection is what it says it is on the tin. Browsers are getting better at warning their users, but libraries are shockingly bad and applications that call them worse at checking for end to end errors and making wise security decisions about the state of the connection. Even basic things like certificate revocation should be a no brainer, but so few libraries enable this by default.
We see this every day in mobile phone apps - it's trivial to get most mobile apps to connect via MITM proxies that don't provide any user feedback that the connection is untrustworthy.
I'd like to see this requirement to be:
"User agent software (mobile app, browser, web service, library) MUST make it clear to the end user in terms they can readily understand that the connection is untrustworthy, and furthermore reject the connection, or to require user intervention to establish an insecure connection. Such failed or insecure connections should be logged."
This would make sure that - regardless if it's the OS, the library or the application - someone owns this interaction, and that is has a clear security objective (no untrusted connections), a usability control that favors security, and lastly a detection control to allow pre-incident monitoring and post-incident re-construction if a user makes a terribly poor choice (for we know they always do given the chance).
I know this doesn't answer your question per se, but you don't mention if you use OpenSSL or WCF or ... I'd be happy to contribute a code snippet if you let me know the platform you'd like.
For a current project, I was thinking of implementing WebDAV to present a virtual file store that clients can access. I have only done Google research so far but it looks like I can get away with only implementing two methods:
GET, PROPFIND
I think that this is great. I was just curious though. If I wanted to implement file uploading via:
PUT
I haven't implemented it, but it seems simple enough. My only concern is whether a progress meter will be displayed for the user if they are using standard Vista Explorer or OSX Finder.
I guess I'm looking for some stories from people experienced with WebDAV.
For many WebDAV clients and even for read only access, you will also need to support OPTIONS. If you want to support upload, PUT obviously is required, and some clients (MacOS X?) will require locking support.
(btw, RFC 4918 is the authorative source of information).
I implemented most of the WebDAV protocol in about a day's work: http://github.com/nfarina/simpledav
I wrote it in Python to run on Google App Engine, and I expect any other language would be a similar effort. All in all, it's about two pages of code.
I implemented following methods: OPTIONS, PROPFIND, MKCOL, DELETE, MOVE, PUT, GET. So far I've tested Transmit and Cyberduck and both work great with it.
Hopefully this can provide some guidance for the next person out there interested in implementing a WebDAV server. It's not a difficult protocol, it's just very dense with abstracted language like 'depth' and 'collections' and blah.
Here's the spec: http://www.webdav.org/specs/rfc4918.html
But the best way to understand the protocol is to watch a client interacting with a working server. I used Transmit to connect to Box.net's WebDAV server and monitored traffic with Charles Proxy.
Bit late to the party, but I've implemented most of the webdav protocol and I can tell with confidence you'll need to implement most of the protocol.
For OS/X you'll need class-2 WebDAV support, which includes LOCK and UNLOCK (I found it particularly difficult to fully implement the http If: header, but for Finder you'll only need a bit of that.)
These are some of my personal findings:
http://sabre.io/dav/clients/windows/
http://sabre.io/dav/clients/finder/
Hope this helps
If you run Apache Jackrabbit under, say, Tomcat, it can be configured to offer WebDAV and store uploaded files. Perhaps that will be a useful model, or even a good enough replacement for the planned implementation.
Apache Jackrabbit Support for WebDAV
Also, you may want to be aware of the BitKinex client (free 30 day trial), which I have found to be a useful tool for testing a WebDAV server.
BitKinex Home Page
We use WebDAV internally to provide a folder-based view of some file shares to clients outside of our firewall. We're using IIS6 for this.
Basically, it boils down to creating a Virtual Directory in IIS that maps to each network file system that you want to make available via WebDAV. Set it up with the content coming from "A share located on another computer" -- use the UNC path to the share for the Network Directory value. We turn on all options except Index this resource. Disable all default content pages. Turn on Windows Integrated Authentication (ours is set up using SSL as well). I have the root set up to deny access to anonymous and allow access to any authenticated user. We also have a wildcard MIME mapping (.* to application/octet-stream). Enable the WebDAV web service extension in IIS. You also need to set up the web server to delegate permissions to all the file servers you may be accessing so it can pass on the user's credentials.
If you have Macintosh clients you may also need an ISAPI filter that maps 401 to 403 errors for Darwin clients. Microsoft and Apple disagree on how to handle the situation when you don't have permission to write to a directory. Apple keeps resending the credentials on a 401 (Access Denied) error, translating it to a 403 (Forbidden) error keeps this from happening. By default Apple likes to write a "dot" file to every directory it accesses. Navigating through directories where you don't have write access will end up crashing the Finder if you don't have the filter. I have source code for this if needed.
This is all off the top of my head. It's possible (probable?) that I may have missed something. Feel free to contact me via the contact information on my web site if you have problems.
We have a webDAV servlet on our web based product.
i've found Apache Jackrabbit a good help for implementing it. however webDav is a serious P.I.T.A on the client side support.
many client implementation differ widely in their behavior and you most likely will have to support several different kinds of bugged implementations.
some examples:
MS vista only supports authentication over SSL
most windows based webDAV client assume your webdav-server/let is a sharepoint server and will act accordingly (thus not according to the webDAV protocol)
one example of this is that you NEED to allow and Unauthenticated LOCK request on the root of your server (ie yourdomain.com/ not yourdomain.com/where/webdav/should/live) else you wont be able to get write acces in MS windows.
(this is a serious P.I.T.A on a tomcat machine where your stuff usualy lives in server.com/servlets/paths/thelocation)
most(all?) versions of MS office respond different to webdav links.
i guess my point is integrating webdav support into an existing product can be a LOT harder then you would expect. and if possible i would advice to use a (semi)-standalone webDAV server such as jackrabbit webdavServer, or apache mod_webdav
I've found OS X's Finder WebDAV support to be really finicky. In order to get read-write support, you have to implement LOCK, in addition to other bits.
I wrote a WebDAV interface to a Postres database, where python modules were stored in the database in a hierarchical folder-like structure. Accessing it with cadaver worked fine, and IIRC a GUI windows browser worked too, but Finder refused to mount the share as anything other than read-only.
So, I don't know if if would give a progress bar. The files I was dealing with were small enough that a read/copy from them was virtually instantaneous. I think a copy of a large file using the Finder would probably give a progress bar - it does for any other type of mounted share.
Here is another open source project for WSGI WebDAV
http://code.google.com/p/wsgidav/
where I picked up the PyFileServer project.