I'm trying to send a message via SNMP version 1 or 2.
I need TLS support for safe transmission.
Does both version support TLS? (I'm using SNMP4j Library in Java)
No, SNMP v1 and v2 send everything in plaintext over the network.
You have to use SNMP v3 together with the security level authPriv.
Note: SNMP v3 also support the security levels noAuthNoPriv and authNoPriv which will send the data unencrypted, too.
Related
I am new to SNMP agent implementation. A confusion regarding the usage of SNMP4J API is, which SNMP4J Api should be used to create the agent? Should it be SNMP4J or SNMP4J-Agent?
An agent is some kind of server: it mainly replies to requests (it may occasionally also send traps to managers).
A manager is a some kind of client: it mainly send requests to agents (it may occasionally also receive traps from managers).
SNMP4J is the library for managers to send requests to remote agents.
SNMP4J-Agent is the library for agents to reply to requests.
So, to write a SNMP agent, you need to use SNMP4J-Agent jar file.
I am not an expert on EWS or TLS 1.2. And I am not sure on how to investigate on this issue.
Basically, I have client application that is heavily using EWS, in a form of pulling data from Exchange server and receiving notifications on subscribed topics from Exchange server.
I have a question from client that I am working for. Does EWS connection, that I use from client app to Exchange server supports TLS 1.2?
Exchange servers can be both 2010 and 2013.
I am not sure how I can confirm this, or this is supported by default.
Any advices or suggestions are welcome.
EDIT:
Client application is written in JavaScript.
The endpoint for Exchange server is https://outlook.office365.com/EWS/Exchange.asmx
As obvious it is https endpoint. Does this means that is is already working well under TLS 1.2 compliance?
TLS is done at the transport layer so for EWS the support depends on the underlying IIS setting. For Office365, the answer is yes (see here).
HTTPS (OWA, Outlook, EWS, Remote PS, etc.) – The support for TLS 1.1 and 1.2 is based on the support in IIS itself. Windows 2008 R2 or later supports both TLS 1.1 and 1.2, though the specific version of Windows may have these disabled or enabled by default. There is another important caveat here: the HTTPS proxy between CAS and Mailbox requires TLS 1.0 in current versions of Exchange Server – so disabling TLS 1.0 between CAS and Mailbox causes the proxy to fail. This is also something we have addressed in the Exchange 2016 Preview. We hope to make this available in a future CU, or you can make a request for it via Support. If you have dedicated roles, you can technically disable TLS 1.0 between the client & CAS, but we still are not recommending this. Office 365 already supports TLS 1.1 & 1.2, if the client supports them.
Put basically the client endpoint support TLS 1.2 so as long as your client supports it you should be good.
Cheers
Glen
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 wanted to understand the mechanism of message encryption and signing used by NetTcpBinding when 'Windows' credentials are being used with Transport security. What if my AD uses NTLM instead of Kerberos? Will the messages still get signed and encrypted?If so, how?
Thanks in Advance,
Akshat
The short answer is that, yes, with NTLM authentication the messages will still get signed and encrypted if you have set the Transport security ProtectionLevel to EncryptAndSign (the default).
Here's an outline of how it works:
selecting Transport security
configures a
WindowsStreamSecurityBindingElement
in the channel stack. This inserts a
stream upgrade provider (see below)
in the NetTcpBinding, message
exchange between the client and
service happens within the .NET Message
Framing Protocol, which provides both
message framing and a mechanism for
client and service to negotiate
stream upgrades, the principal use of
which is to establish transport
security. If there is a stream
upgrade provider configured in the
channel stack, this will be invoked
during the Preamble stage of the
Framing Protocol when the client
opens the channel.
the upgrade
provider for
WindowsStreamSecurityBindingElement invokes an SSPI handshake between the client and the server using the SPNEGO security package: in the NetTcpBinding this will normally result in Kerberos being selected as the underlying security provider if available, but will choose NTLM if not.
if NTLM is the resulting authentication provider, the SSPI handshake will involve the three-leg NTLM challenge-response exchange of tokens described in the NTLM specification. This protocol includes a mechanism for exchanging keys for message signing and encryption. Once the SSPI handshake has generated an appropriate security context, thereafter all messages exchanged are signed and encrypted in the sending channel stack's stream upgrade provider, and decrypted and verified in the receiving channel stack's stream upgrade provider, in each case by using calls to the NTLM security provider via the abstracted SSPI message support functions.
This is a Microsoft propriety implementation and not properly documented and perhaps on purpose to prevent intruders to take advantage of it.
As far as I know, this usually happens at the TCP level with a special token is generated by the user's credentials and passed along with the request. This is intercepted by windows security channel and authenticated against the AD.
This token is used as a key (or as a basis for generating the key) for encrypting the communication.
I think if you look at the TCP packet, you must be able to see the token - although I have never seen it.
If you are doing this all in code then you can find out the options here (search for 'NetTcpBinding'). Transport security is via Windows builtin TLS.
The diagram here should be helpful for your scenario.
I am trying to use gmail's SMTP server smtp.gmail.com to send mails using C in Windows. I am able to connect to port 587 of the server, however the server responds by saying that STARTTLS/TLS is needed. Is there any Windows API call for starting a TLS connection ?
Should I even consider writing this application in C or use Python ?
Edit: Has anyone been able to send a mail by connecting to smtp.gmail.com using Telnet ? What I got was
220 mx.google.com ESMTP g4sm73428740wae.2
HELO hello
502 5.5.1 Unrecognized command. g4sm73428740wae.2
HELO hello.hello
250 mx.google.com at your service
MAIL FROM:a#gmail.com
530 5.7.0 Must issue a STARTTLS command first. g4sm73428740wae.2
STARTTLS
220 2.0.0 Ready to start TLS
MAIL FROM:a#gmail.com
and the connection is lost
You are going to need either a .NET wrapper around Microsoft's SmtpClient to create a DLL that can use the .NET features for SSL/TLS support through SMTP or use OpenSSL to handle the connections.
It would probably be beneficial for you to write this in C++. I am not familiar with Python, but I am sure there are libraries such as TLS Lite (Edit: see below, smtplib apparently provides you this functionality too).
Edit: Based on your edit, you have to have a program that knows how to handle the STARTTLS command. GMail requires secure connections and a username/password by default on all SMTP connections. You can connect to port 25, but you'll have to switch to the secure port after the initial connection. This is why, when you go to http://mail.google.com, it automatically switches to https connection. There was a whole big discussion about this on the Internet some time ago..
If you do not want to use OpenSSL or other third-party SSL/TLS library, then you can use Microsoft's own SSPI/SChannel APIs instead. It can be used on top of a socket, where the socket handles the low-level input/output of bytes, and you pass the bytes in/out of SSPI/SChannel functions for processing.
If you choose to write it in C then you will need a library like GNU SASL, which enables secure SMTP authentication. If you opt for C++ as was previously suggested then I would look at VMime, which is a free C++ library that uses GSASL. There is an example on the site that shows how to connect to GMail.