search for: mitms

If I read this correctly, starttls will fail due to the MITM attack. That is the client knows security has been compromised. Using SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use "may" for security, the message would go though unencrypted. Correct??? Is there something to enable for perfect forward security with starttls? ? Original Message ? From: s.arcus at

Thunderbird has a MITM vulnerability with its otherwise rather groovy auto-configuration feature. The problem is that it makes requests via HTTP to retrieve the auto configuration information. This allows a black hat (e.g. the NSA) to modify the results sent to the client, and the client has no way to verify the results have not been tampered with. This could even allow the black hat to act

>> Lest anyone think STARTTLS MITM doesn't happen, >> >> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ Right, the attack does happen, but it can be prevented by properly configuring the server and client. >> Not only for security, I prefer port 993/995 as it's just plain >> simpler to initiate SSL from the get-go

Lest anyone think STARTTLS MITM doesn't happen, https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/ Not only for security, I prefer port 993/995 as it's just plain simpler to initiate SSL from the get-go rather than to do some handshaking that gets you to the same point. Joseph Tam <jtam.home at gmail.com>

On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > Thunderbird has a MITM vulnerability with its otherwise rather groovy > auto-configuration feature. > https://librelamp.com/FooBird#security > > has what I think would be the easiest solution while keeping the > ability to auto-configure stuff. As for LibreSSL et al, perhaps you could mention all your concerns on

Hello, On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > Thunderbird has a MITM vulnerability with its otherwise rather groovy > auto-configuration feature. > > The problem is that it makes requests via HTTP to retrieve the auto > configuration information. > > This allows a black hat (e.g. the NSA) to modify the results sent to the > client, and the client has

Hi, This is just a quick note to state that the recently reported SSL/TLS MITM attack[1] *does not* affect SSH. Like SSL/TLS, SSH supports key and parameter renegotiation, but it is not vulnerable because a session identifier is carried over from the first key exchange into all subsequent key exchanges. Technical details: In SSL, key exchanges and subsequent renegotiations are completely

Robert Wolf wrote: >> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you >> have enabled something like cram-md5. > > Hi, > > exactly, this is the reason, why plain-text is still needed. You don't need > encryption for authentication, if you have secure authentication. Without > knowing original password, the MITM cannot generate correct hash

Am 6. Dezember 2014 13:10:58 MEZ, schrieb Reindl Harald <h.reindl at thelounge.net>: > >Am 06.12.2014 um 06:56 schrieb Jan Wide?: >> If you add disable_plaintext_auth=yes ssl=required settings, then >> dovecot will drop authentication without STARTTLS. But damage will be >> done, client will send unencrypted (or in this scenario MD5 or SHA512 >> hash)

On 29/05/20 11:27 pm, mj wrote: > Thanks to all who participated in the interesting discussion. > > It seems my initial thought might have been best after all, and > discontinuing port 143 might be the safest way proceed. Yes and no. Some of the attack vectors mentioned are not reasonable and it really depends on the client. Thunderbird, for example, used to have settings for

On 08/23/2015 07:25 AM, Always Learning wrote: > > On Sat, 2015-08-22 at 08:05 -0700, Alice Wonder wrote: > >> Thunderbird has a MITM vulnerability with its otherwise rather groovy >> auto-configuration feature. > >> https://librelamp.com/FooBird#security >> >> has what I think would be the easiest solution while keeping the >> ability to

On Sun, 2015-08-23 at 07:57 -0700, Alice Wonder wrote: > I stopped using Fedora because as soon as it was stable it was end of > life and I was forced to install a new bleeding edge unstable version. I am 'conservative' too. Once something is working well I do not wish to change it unless there is a compelling conspicuous advantage. > I do not like bleeding edge for most

http://marc.info/?l=postfix-users&m=129952854117623&w=2 Dovecot doesn't have this bug. It discards all buffered data when STARTTLS command runs. (Why do I think I've heard about this bug before? Or at least the same type of way to exploit it? Maybe there was another similarly exploitable bug.)

Hello, Which one of these ensures that SIP packets are sent and received in a secure format so that users using public wifi don't allow MITM type of attacks or others can't read the plaintext SIP packet info. VPN is not an option. Looking for 2nd most secure to VPN. P.S. Are both options part of the configs of Asterisk or need modules to be selected and installed before doing the

Rowland penny via samba ha scritto il 27/08/20 alle 15:49: > On 27/08/2020 14:19, Piviul via samba wrote: >> >>> >>> Microsoft is enforcing more securitybut it's Microsoft that develop >>> NetBIOS and LLMNR and if it's enforcing >> security should enforce these protocols or remove them from their OS >> isn't it? > > Microsoft

Rowland penny via samba ha scritto il 27/08/20 alle 16:43: > [...] > Netbios is intrinsically tied to SMBv1 and? LLMNR (Link-Local Multicast > Name Resolution) is also connected in a way, it allows name resolutions > without a nameserver. So, if you are using it, I personally wouldn't, > ever heard of MITM ? Just to understand a little more... NetBIOS with a wins server

It does, thanks. So if the password is known, or the KDC compromised, then in principle MITM becomes possible? On 2017-08-14 15:28, Andrew Bartlett wrote: > On Mon, 2017-08-14 at 06:45 -0400, Daniel Benoy via samba wrote: >> Is it perhaps using your password somehow? Like, if an attacker knew >> the >> password that the client is using to connect, would it then be able to

> My fear is the exploit-s'kiddie problem. Are there common exploits for man-in-the-middle? I've never seen one. I've seen rootkits, crackers, DoS tools, etc. But never anything as sophisticated as mitm. > I see no reason why anyone would constantly scan huge netblocks of cable > modem users, looking for the occasional target to haX0r. But that doesn't > stop the

Hi All, >From Changelog with 3.8: "The experimental "gssapi" support has been replaced with the "gssapi-with-mic" to fix possible MITM attacks.The two versions are not compatible." I am using OpenSSH-3.6 with Simon's patch and OpenSSH-3.7 built with GSSAPI support. The latest version OpenSSH-3.8 is not working with 3.6 or 3.7 with GSSAPI authentication. I

Hello everybody, Here are some thoughts about the authentication scheme to be used in tinc. The current scheme (see CVS version, revision CABAL) does this: Client Server --------------------------------------- send_id(u) send_challenge(R) send_chal_reply(H) send_id(u) send_challenge(R)