I've received the notice that one of my servers will disable early TLS and use only TLS1.2. And they said to upgrade the protocols from my soap integrations.
Is it really possible? And so, how do i do that?
You will need to ensure that whatever you use that calls to Magento utilizes TLS1.2 (or at least supports it as a fallback).
For example, if you wrote a program to call Magento SOAP web services in Java, you would need to make sure that it was a version of Java that supported TLS1.2, and that your configuration of Java utilized that as a protocol.
Related
Currently if I scan(from both UI and CLI) using ZAProxy it sends HTTPS Traffic using HTTP1.1 version, Do we have any Support or Workaround to send HTTPS Traffic using HTTP2.0 version in ZAProxy.
Any help on this is much appreciated
No ZAProxy does not support HTTP/2 at this time.
The Paros networking layer used by ZAP is old, and lacks support of modern options such as HTTP/2. They planned to replace this but there is no ETA as of now.
refer the thread : https://github.com/zaproxy/zaproxy/issues/1765
I'm trying to implement a sip server for connecting to from an HTML sip client(made using sipml5). During my research into doing this I've come across sip over web-sockets which might be useful to me, however, I am unsure if a user agent connecting through sip over web-sockets to a compatible server would then be able to successfully make a call to some one using an incompatible server(i.e. calling from SIP over web-sockets to true SIP).
I know webrtc2sip can be used for connecting to legacy networks but I would rather avoid using another proxy if at all possible. So, is it possible to connect to a compatible SIP server using SIP over web-sockets then make a call from this user agent to another that does not support SIP over web-sockets without using a gateway?
You are right, SIP over Websockets is a draft, not specification. And I do not know many SIP vendors who support this draft.
Possible solution is truly websocket-SIP gateway. For example Flashphoner Web Call Server is implemented as a gateway which works through websockets with browser and works via SIP(TCP and UDP) with SIP servers. Therefore it is compatible with any server that supports RFC3261 - standard SIP specification.
Brief signaling scheme is:
Browser - [Websockets] - Web Call Server - [SIP TCP, UDP] - any SIP Server
Brief streaming scheme:
Browser - [WebRTC = SRTP, DTLS, ICE, STUN ] - Web Call Server - [RTP UDP] - any SIP/RTP Server
An alternate way is to use kamailio as it understands both sip and ws sip .
when you say "implementing a sip server " is it a simple registrar or proxy server or you want cal control logic / presence other features ?
In all cases kamailio fulfills all requirements , plus it is opensource .
Mobicents SIP Servlets Example already provides a B2BUA Application taking care of that for you. The Media is peer to peer (or through a TURN Relay Server) but if you need to bridge to a Media Server, you can indeed patch the SDP Body to make the media of each party go through the Media Server (pending it supports Media related codecs from WebRTC, DTLS-SRTP etc) to add conferencing, recording type of capabilities.
I want to develop a web application in which client calls a service on server to do some action which involves some processing. Server will do all the necessary processing and when the updated data is ready it will push that data to client. Currently I am considering two approaches: -
1. Using ASP.NET WEB API with SignalR
2. Using WebSockets with WCF in .NET 4.5.
My server will be on Windows Server 2012 but majority of my client will be IE 9 which I think do not support WebSockets.
As written in the SignalR documentation that it automatically falls to Long Polling if WebSockets support is not present without changing the application code. Whether this is also supported by WebSockets in .NET 4.5 or I have to do it manually. Means whether I have to implement both the Pull method and push method on the server.
Please guide me, which approach I will have follow.
In later use case I want to build this web application using PhoneGAP to create mobile app for iOS, Android & Windows Phone.
WebSockets does not fall back to longpolling (that doesn't really make sense). SignalR is a higher level abstraction over http transports and that's why it does the fallback and other things (like provide a nice programming model over a connection).
If you choose to use websockets on ASP.NET (not sure about WCF) you'll be programming against raw sockets (this means reading/writing array segments etc) and doing a good job at that is hard. SignalR does this for you and will fallback to several other transports (forever frame, server sent events, longpolling) if websockets isn't available on client or server.
Regarding clients, if you choose to use SignalR you'll need to use a SignalR client. We only have support for javascript and .NET (silverlight, windows phone 8, winrt, .NET 4 and .NET 4.5). Some people have written clients for other platforms including iOS and Android but we don't maintain them so I can't speak to how up to date they are.
I'd recommend you use SignalR so you can focus on your application logic instead of messing with the low level programming model of websockets.
You could start with the ASP.NET Tutorial http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
After this tutorials you know all the basic thing you need to know about SignalR
I can confirm that the fallback works automatically. If websockets transport can't be used, ServersentEvents transport would be used.. and so on.. the last transport protocol is longpolling.
Our SignalR server is a .NET 4.5 framework app, hosted in an ASP.NET MVC App using 4.5 dlls on a windows 2012 server. The application pool is ASP.NET 4.0.
A .NET 4.5 client on a Windows 8 or a windows 2012 server seems to use websockets.
The same .NET client on a Windows 7 machine (even with framework 4.5 installed) falls back to serversent events transport automatically.
With Signalr javascript clients on a browser, a similar thing happens:
Chrome/Safari/other browsers that support websockets seem to use websockets.
IE/other browsers that don't support websockets, but are relatively late versions seem to use serversentevents.
From experience, serversentevents is not very bad, therefore don't be put off if websockets isn't being used and certainly don't use that as the sole factor against using signalR as the benefits are many.
Hope this helps.
Does anyone have a websocket connection working with an application proxy (e.g. burp or zap)?
For example, I have a working version of jWebSockets with works perfectly on my local machine.
However, when I intercept with Burp or Zap the connection times out and I get no server response back.
I have increased the timeout settings on the server side but this does not make a difference.
I have also tried using the invisible proxy option.
Thank you.
There are very few tools that support web sockets right now as its really a completely new protocol.
The current version of ZAP (1.4.1) wont, but the next major version will: http://code.google.com/p/zaproxy/wiki/GSoC2012_WebSockets
If you can build ZAP from the trunk then it will support web sockets - build instructions here: http://code.google.com/p/zaproxy/wiki/Building
It will allow you to view web socket traffic, intercept and change it and fuzz it to try and find vulnerabilities.
Let us know if you have any problems with it, eg via the ZAP developer group: http://groups.google.com/group/zaproxy-develop
Simon (ZAP Project Lead).
Update - Web Sockets support in ZAP is now available in the weekly cross-platform releases, which can be downloaded from http://code.google.com/p/zaproxy/downloads/list so you dont have to build it yourself
I was doing AJAX implementation and would like to use Websocket when the client web browser supports it. Is there any frameworks that supports Websocket but falls-back to other methods when it detects the client side doesn't support Websocket.
There is also Atmosphere
http://atmosphere.dev.java.net
which support both client and server.
Yes sort of see www.kaazing.org
Kaazing Gateway supports all major browsers (Firefox version 1.5 and higher, Internet Explorer version 5.5 and higher, Safari version 3.0 and higher, Opera version 9.5 and higher, and Google Chrome version 0.2 and higher).
Socket.io is designed for this.
http://socket.io/
It is purely javascript that tries several different transport methods including XHR long-polling, WebSocket and FlashSocket amongst others.
You could also use Nirvana from www.my-channels.com.
When WebSocket is not supported it will fall back to a Comet based approach transparently.
Of course, you could try using jWebSocket, it is a pure Java/JavaScript high speed bidirectional communication solution for the Web - secure, reliable and fast. jWebSocket is provided to you to create innovative HTML5 based streaming and communication applications on the web. HTML5 WebSockets will replace the existing XHR approaches as well as Comet services by a new flexible and ultra high speed bidirectional TCP socket communication technology. jWebSocket is an open source Java and JavaScript implementation of the HTML5 WebSocket protocol with a huge set of extensions. Some demos or examples can be seen for you in the website, you can visit it here: https://jwebsocket.org/